The aim of this document is to showcase some interesting capabilities of the declarative infrastructure monitoring powers of IOX.

Pre-requisites

• What is IOX?
• How do I initialize IOX in my repo?
• Summary:
  • IOX is to observability what Terraform is to infra.
  • Powered by last9/iox-registry
  • Reusable modules across multiple metric sources.
  • Input - json, output - observable infra tying services and infrastructure.

Sample infrastructure

• Let us say you want to observe your infrastructure in AWS region ap-south-1 with the following components:
  1. AWS EKS for managed Kubernetes.
  2. AWS RDS MySQL instances are being used by the EC2 instances.

Stage-1 - Blank slate

1. Observe RDS clusters by specifying their names.

   1. Create a file iox/aws_components_ap-south-1.hcl

      extends aws_rds_logical_cloudwatch "app1_rds_logical" {
        source_uri = "<https://github.com/last9/iox-registry/releases/download/v0.0.27/aws_rds_cloudwatch.hcl>"
        vars = {
          using  = "ap-south-1"
          inputs = <<-EOF
          [
            {
              "DBInstanceIdentifier": "main-instance-1",
              "namespace": "example.io",
              "service": "service1"
            },
            {
              "DBInstanceIdentifier": "reader-instance-1",
              "namespace": "example.io",
              "service": "service-1"
            }
          ]
          EOF
        }
      }
      
      extends aws_rds_physical_cloudwatch "app1_rds_physical" {
        source_uri = "<https://github.com/last9/iox-registry/releases/download/v0.0.27/aws_rds_cloudwatch.hcl>"
        vars = {
          using      = "ap-south-1"
          inputs = <<-EOF
          [
            {
              "DBInstanceIdentifier": "main-instance-1",
              "namespace": "example.io",
              "service": "service1"
            },
            {
              "DBInstanceIdentifier": "reader-instance-1",
              "namespace": "example.io",
              "service": "service-1"
            }
          ]
          EOF
        }
      }
      

   2. Create a credential file config.hcl

      • If you have onboarded your infrastructure through a Last9 read only user.
      • If you have onboarded your infrastructure through cross account role

   3. Check-in this file to master.

   4. This will trigger a CI/CD automation, which will (seamlessly) lead to observing the following infra on your Last9 dashboard. We have blurred out the service name prefix

      

• Pros
  • Just by adding RDS cluster names, we have:
    1. Tagged the RDS clusters to service-1 and namespace example.io . If you want to change the way you want to view them or move reader-instance-1 - the change is just a json edit away.
    2. Unlocked - SLIs, metrics, and the ability to set SLO on supported components.
• Cons
  1. This did the trick, but we have hard-coded the cluster names. We can surely do better than that.

Stage-2 - Tag-based observability

• Questions
  • Do I have to specify the cluster name every time a new cluster is added?
  • What if my infra is dynamically provisioned?
• One answer to rule them all:
  • We support tags!

1. Replace the contents of iox/aws_components_ap-south-1.hcl

   extends aws_rds_logical_cloudwatch "app1_rds_logical" {
     source_uri = "<https://github.com/last9/iox-registry/releases/download/v0.0.27/aws_rds_cloudwatch.hcl>"
     vars = {
       using      = "cloudwatch_ap-south-1"
       tag_filter = "Team='db'"
       namespace  = "example.io"
       service    = "service1"
     }
   }
   

2. Check-in, commit to master and Last9 CI/CD will update the dashboard.

   The above snippet assumes that your RDS clusters are tagged with Team=db . This can be any tag. IOX will auto-discover the corresponding tagged infra and keep on updating the infrastructure views as and when new components are added.

   What happens to deleted components? We keep their data for 7 days and if no metrics are received beyond that period, they will disappear from the dashboard.