application.conf

# The jobs/data-sets to monitor
check-groups: {
  # This is an optional subtitle to show in the dashboard
  namespace: "Test dashboard"
  # Where to store temporary files, that is used to store debug lines that can
  # be seen in te /group/gid/job/stdout endpoint. You only need to change this
  # setting if you have more than one instance of Greenish running on the same
  # machine. If you do not, then there will be race condition between the two
  # instances.
  scratch-dir: "/tmp/greenish/stdout"
  # The frequency of pulling data
  refresh-in-seconds: 30
  # The binding address of the HTTP server
  binding-address: "127.0.0.1"
  # The port on which the server is running
  port: 8080
  # Not all jobs are available at the begining of a period, an hourly job might
  # systematically appear at the end of an hour. A monthly job at the end of
  # the month, and etc. This is a global setting, for specifying the deafult
  # period-offset, if a job is expected to arrive at the end of the period, then
  # offset should be 1.
  # This set can be overridden by `group-period-check-offset` at group level,
  # and `job-period-check-offset` at job level.
  default-period-check-offset: 1
  # Default period pattern. Please see job-entries' period-pattern property for
  # more information
  default-period-pattern: "yyyy-MM-dd-HH-mm"
  # Default run frequency. Please see job-entries' job-run-frequency property
  # for more information
  default-job-run-frequency: "daily"
  # Default timezone. Please see job-entries' timezone property for more
  # information
  default-timezone: "US/Samoa"
  # Default lookback. Please see job-entries' lookback property for more
  # information
  default-lookback: 270
  # Default great-at. Please see job-entries' great-at property for
  # more information
  default-great-at: 30
  # Default normal-at property. Please see job-entries' normal-at pattern
  # property for more information
  default-normal-at: 40
  # Default warn-at property. Please see job-entries' warn-at pattern
  # property for more information
  default-warn-at: 50
  # Default error-at property. Please see job-entries' error-at pattern
  # property for more information
  default-error-at: 60

  # Default start-at property. This is basically where we can define
  # when the oldest possible available datasets. This is useful, for
  # example if we add a new job to be monitored, and the lookback is
  # 10, for the next 10 hours the job starts complaining because some
  # data is missing, even though those are correctly missing (the job
  # didn't exist for those periods).  The default value is 0. The data
  # is expressed in Unix timestamp epoc (seconds) This property can be
  # updated both at group and job level
  default-start-at: 0
  # Default owner of all the following jobs, can be used for escalation
  # purposes. This appears under the Job view in the dashboard. HTML tags are
  # supported.  This setting is Optional.
  # Can be overridden by group-owner and job-owner settings
  default-owner: "SRE"
  # Default info for all the following jobs, can be used for adding extra
  # information to be shown next to the job in the dashboard. HTML tags are
  # encouraged here. Multiline strings are introduced using `"""` like in
  # Python and Scala. If you start every new line with `|`, then every leading
  # space to that character will be ignored. This setting is Optional. Can be
  # overridden by group-info and job-info settings
  default-info: """|<a href="link">
                   |Link
                   |</a>"""
  # Additional environment variables to be passed
  # to the monitoring scripts, you can AWS profile
  # names here, for example:
  # AWS_PROFILE: "reader-profile"
  # `env` can be set on both grup and job level
  env: {
    VAR1: "foo"
    # `secure(...)` pattern tells Greenish that the data should be kept
    # secret and not returned in any of the endpoints.
    VAR2: "secure(bar)"
  }
  # Job groups, a group is a set of jobs/data-sets
  # that have some sort of logical relation
  groups: [
    {
      # Pick a human friendly name here
      group-name: "Group1",
      # More or less like `default-period-check-offset`, but this scoped to the
      # group only.  Can be overridden by `job-period-check-offset`.
      group-period-check-offset: 2
      # More or less like `default-period-pattern`, but this scoped to the
      # group only.  Can be overridden by `period-pattern`.
      group-period-pattern: "yyyy-MM-dd-HH"
      # More or less like `default-job-run-frequency`, but this scoped to the
      # group only.  Can be overridden by `job-run-frequency`.
      group-job-run-frequency: "hourly"
      # More or less like `default-timezone`, but this scoped to the
      # group only.  Can be overridden by `timezone`.
      group-timezone: "US/Alaska"
      # More or less like `default-lookback`, but this scoped to the
      # group only.  Can be overridden by `lookback`.
      group-lookback: 24
      # More or less like `default-great-at`, but this scoped to the
      # group only.  Can be overridden by `great-at`.
      group-great-at: 0
      # More or less like `default-normal-at`, but this scoped to the
      # group only.  Can be overridden by `normal-at`.
      group-normal-at: 1
      # More or less like `default-warn-at`, but this scoped to the
      # group only.  Can be overridden by `warn-at`.
      group-warn-at: 2
      # More or less like `default-critical-at`, but this scoped to the
      # group only.  Can be overridden by `critical-at`.
      group-error-at: 3

      # Just like default-start-at, but for the group level
      group-start-at: 1
      # group level owner, more or less default-owner but at the group level
      group-owner: "Reporting"
      # group level info, more or less default-info but at the group level
      group-info: "Group info"
      env: {
        VAR1: "baz"
        VAR3: "bazooka"
      }

      # A group can have many jobs/data-sets to monitor
      job-entries: [
        {
          # Pick a human friendly name here
          job-name: "Job1"
          # An id to be used as a label for the exported Prometheus emtrics.
          # Each job will export internal metrics in a label to Prometheus,
          # which is controlled here. It is best to make sure that the id is
          # unique per job. But, it is not enforced.
          #
          # In case this option is skipped, the combination of `group` and
          # `job` name is chosen, turned into lower-case and all the whitespace
          # characters, and hyphens are replaced with _.
          # Prometheus IDs should match this pattern:
          # "[a-zA-Z_][a-zA-Z0-9_]*"
          prometheus-id: "job_1"
          # A check-command is any executable program/script that, takes
          # `period` in the form of `period-pattern` below as the last
          # argument, and exits with 0 only if successful. You an add arguments
          # to the script here: `/etc/check job1 production` is perfectly
          # allowed.
          # In case the Greenish failed to run the script, please wrap it in a
          # shell-script and add shebang at the top. Java Process Builder can
          # fail to recognize some scripts/programs.
          check-command: "/tmp/first_script",
          # A valid date/time pattern. Please consult the following page for
          # more info:
          # https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#patterns
          # If the data-set is expected to appear at the first day of every
          # month, You can write a pattern like: yyyy-MM-01
          period-pattern: "yyyy-MM-dd-HH"
          # What is the expected run-frequency of the job?
          # Supported values: hourly, daily, monthly, annually. Unix-Cron-style
          # syntax is also accepted here: `0 * * * *` runs at minute zero every
          # hour, more or less like `hourly`. Cron-style reacts differently to
          # `period-check-offset` settings. In the case of cron, you might want
          # to increase the offset by 1.
          job-run-frequency: "hourly"
          # More or less like `group-period-check-offset`, but this scoped to
          # this job only.
          job-period-check-offset: 3
          # What is the timezone of the periods in the data set. If you have two jobs,
          # one produced in Cairo, and follows Cairo timezone, and another in Canada
          # which follows UTC, you can configure them accordingly using this field.
          # Greenish respects the option when calling the monitoring script.
          timezone: "UTC"
          # How far back do you want to monitor? in this example we monitor
          # the last 24 datasets (hours)
          lookback: 24
          # The following are hints for Greenish, to check if a job is
          # at "great", "normal", "warn" or "critical" state
          great-at: 0
          normal-at: 1
          warn-at: 2
          error-at: 3
          # Just like default-start-at, but for the job only
          start-at: 2
          # job level owner, more or less group-owner but at the job level
          job-owner: "Data"
          # job level info, more or less group-info but at the job level
          job-info: "Job info"
          env: {
            VAR2: "bazomba"
            VAR3: "bada"
            VAR4: "badam"
          }
        },
        {
          job-name: "Job2"
          prometheus-id: "job_2"
          check-command: "/tmp/second_script job2",
          period-pattern: "yyyy-MM-dd-HH"
          job-run-frequency: "daily"
          timezone: "UTC"
          lookback: 24
          great-at: 0
          normal-at: 1
          warn-at: 2
          error-at: 3
        },
        {
          job-name: "Job5"
          check-command: "/tmp/second_script job5",
        },
        {
          job-name: "Job7"
          check-command: "/tmp/second_script job7",
          job-run-frequency: "0 * * * *"
        }
      ]
    },
    {
      group-name: "Group2",
      job-entries: [
        {
          job-name: "Job3"
          prometheus-id: "job_3"
          check-command: "/tmp/third_script",
          period-pattern: "yyyy-MM-dd"
          job-run-frequency: "monthly"
          timezone: "UTC"
          lookback: 3
          great-at: 0
          normal-at: 1
          warn-at: 2
          error-at: 3
        },
        {
          job-name: "Job4"
          prometheus-id: "job_4"
          check-command: "/tmp/fourth_script",
          period-pattern: "yyyy-01-01"
          job-run-frequency: "annually"
          timezone: "UTC"
          lookback: 3
          great-at: 0
          normal-at: 1
          warn-at: 2
          error-at: 3
        },
        {
          job-name: "Job6"
          check-command: "/tmp/second_script job6",
          env: {
            VAR1: "baz"
            VAR3: "bazooka"
          }
        }
      ]
    }
  ]
}

# This section is used to tune the performance of Greenish
akka {
  # This is the thread-pool for running monitoring scripts
  # If Greenish is unresponsive, you should look into this.
  # As, monitoring scripts are expected to be IO bound, you
  # may want to maximize parallelism.
  refresh-dispatcher {
    type = Dispatcher
    executor = "thread-pool-executor"
    thread-pool-executor {
      fixed-pool-size = 100
    }
    throughput = 1
    mailbox-capacity = -1
  }
}