Skip to content

Manifest File

The abc.manifest.yml manifest file serves as the control center for all aspects related to the Observability Suite. The following table describes the sections contained within the manifest file, and the example shows the current manifest file code populated with information from the ERE Team's sample repository.

Section Description
Name and ID Versioning and naming information to identify service ownership
Service Dependencies Identify service dependencies, including Lambdas, Fargate, Kinesis streams, OpenSearch, Stripe, Contentful, and more
Observability Metadata Identification, type, and latency category for your service
Default Monitors Standard monitors on error rates and availability for your service

Example manifest file

This example uses a demo service called Reliability Bob.

schema_version: 1

name: Reliability Bob
app: reliability-bob
workload: rel-enable
platformVersion: '2'
component_tag: reliability-bob

# Service dependencies
dependencies:
  - name: Reliability Alice
    component_tag: reliability-alice
    type: netty
  - name: External API (Json Placeholder)
    component_tag: reliability-bob-json-placeholder
    type: external http
  - name: Kinesis (stream1)
    component_tag: reliability-dana-stream1
    type: kinesis
  - name: Reliability Dana
    component_tag: reliability-dana
    type: lambda
  - name: DynamoDB (user-table)
    component_tag: reliability-dana
    type: dynamodb

observability:
  title: Reliability Bob
  team: Reliability
  availability: important   # critical: 99.9%, essential: 99.5%, important: 99.0%
  type: netty
  p90_latency_seconds: 1
  operation: trace.netty.request

  notifications:
    opsgenie: opsgenie-Reliability-Enablement_Datadog

  monitors:
    - type: http
      error_percent_threshold: 0.5
    - type: custom
      name: cpuPercentage_Above_70
      query: avg(last_5m):avg:ecs.fargate.cpu.percent{service:${service},env:${env}}
        by {version} > 70
      monitor_type: metric alert
      message: CPU Percentage above 70

Reference documentation for creating a monitor request body

See the Datadog Documentation to create a monitor request body.

Note

The only notable change team needs to adopt is to use CamelCase approach for options in manifest.yml.

e.g. You can use options field for say Evalaution Delay and Thresholds as below. Other fields can also be passed in similar fashion.

options:
EvaluationDelay: 300
Thresholds:
  Critical: 0
  Warning: 1
  OK: 2