## All options defined here are available to all instances.
#
init_config:

    ## @param global_custom_queries - list of mappings - optional
    ## See `custom_queries` defined below.
    ##
    ## Global custom queries can be applied to all instances using the
    ## `use_global_custom_queries` setting at the instance level.
    #
    # global_custom_queries:
    #   - metric_prefix: ibm_db2
    #     query: <QUERY>
    #     columns: <COLUMNS>
    #     tags: <TAGS>

    ## @param service - string - optional
    ## Attach the tag `service:<SERVICE>` to every metric, event, and service check emitted by this integration.
    ##
    ## Additionally, this sets the default `service` for every log source.
    #
    # service: <SERVICE>

## Every instance is scheduled independent of the others.
#
instances:

    ## @param db - string - required
    ## The name of the database to establish a connection with.
    #
  - db: <DATABASE_NAME>

    ## @param username - string - required
    ## The database user to authenticate as.
    #
    username: <USERNAME>

    ## @param password - string - required
    ## The password of `username`.
    #
    password: <PASSWORD>

    ## @param host - string - optional
    ## The hostname used to connect to a remote or uncataloged database.
    #
    # host: <HOSTNAME>

    ## @param port - integer - optional - default: 50000
    ## The port used to connect to a remote or uncataloged database.
    #
    # port: 50000

    ## @param tls_cert - string - optional
    ## The path to a SSL certificate to use, when connecting to a database in a secure fashion. It
    ## has to be accessible and readable by the agent user.
    #
    # tls_cert: <TLS_CERT>

    ## @param use_global_custom_queries - string - optional - default: true
    ## How `global_custom_queries` should be used for this instance. There are 3 options:
    ##
    ## 1. true - `global_custom_queries` override `custom_queries`.
    ## 2. false - `custom_queries` override `global_custom_queries`.
    ## 3. extend - `global_custom_queries` are used in addition to any `custom_queries`.
    #
    # use_global_custom_queries: 'true'

    ## @param custom_queries - list of mappings - optional
    ## Each query must have 3 fields:
    ##
    ## 1. metric_prefix - This is what each metric will start with.
    ## 2. query - This is the SQL to execute. It can be a simple statement or a multi-line script.
    ## 3. columns - This is a list representing each column, ordered sequentially
    ##              from left to right. The number of columns must equal the number
    ##              of columns returned in the query.
    ##              There are 2 required pieces of data:
    ##                a. name - This is the suffix to append to the metric_prefix
    ##                          in order to form the full metric name. If `type` is
    ##                          `tag`, this column will instead be considered a tag
    ##                          and will be applied to every metric collected by
    ##                          this particular query.
    ##                b. type - This is the submission method (gauge, count, rate, etc.).
    ##                          This can also be set to `tag` to tag each metric in the row
    ##                          with the name and value of the item in this column. You can
    ##                          use the `count` type to perform aggregation for queries that
    ##                          return multiple rows with the same or no tags.
    ##
    ##               Columns without a name are ignored, put this for any column you wish to skip:
    ##                 - {}
    ## 4. tags (optional) - A list of tags to apply to each metric.
    #
    # custom_queries:
    #   - metric_prefix: ibm_db2
    #     query: SELECT files_closed, tbsp_name FROM TABLE(MON_GET_TABLESPACE(NULL, -1))
    #     columns:
    #     - name: tablespace.files_closed
    #       type: monotonic_count
    #     - name: tablespace
    #       type: tag
    #     tags:
    #     - test:ibm_db2

    ## @param tags - list of strings - optional
    ## A list of tags to attach to every metric and service check emitted by this instance.
    ##
    ## Learn more about tagging at https://docs.datadoghq.com/tagging
    #
    # tags:
    #   - <KEY_1>:<VALUE_1>
    #   - <KEY_2>:<VALUE_2>

    ## @param service - string - optional
    ## Attach the tag `service:<SERVICE>` to every metric, event, and service check emitted by this integration.
    ##
    ## Overrides any `service` defined in the `init_config` section.
    #
    # service: <SERVICE>

    ## @param min_collection_interval - number - optional - default: 15
    ## This changes the collection interval of the check. For more information, see:
    ## https://docs.datadoghq.com/developers/write_agent_check/#collection-interval
    #
    # min_collection_interval: 15

    ## @param empty_default_hostname - boolean - optional - default: false
    ## This forces the check to send metrics with no hostname.
    ##
    ## This is useful for cluster-level checks.
    #
    # empty_default_hostname: false

## Log Section
##
## type - required - Type of log input source (tcp / udp / file / windows_event)
## port / path / channel_path - required - Set port if type is tcp or udp.
##                                         Set path if type is file.
##                                         Set channel_path if type is windows_event.
## source  - required - Attribute that defines which integration sent the logs.
## encoding - optional - For file specifies the file encoding, default is utf-8, other
##                       possible values are utf-16-le and utf-16-be.
## service - optional - The name of the service that generates the log.
##                      Overrides any `service` defined in the `init_config` section.
## tags - optional - Add tags to the collected logs.
##
## Discover Datadog log collection: https://docs.datadoghq.com/logs/log_collection/
#
# logs:
#   - type: file
#     source: ibm_db2
#     path: /home/db2inst1/sqllib/db2dump/db2diag.log
#     log_processing_rules:
#     - type: multi_line
#       name: new_log_start_with_date
#       pattern: \d{4}\-(0?[1-9]|[12][0-9]|3[01])\-(0?[1-9]|1[012])