Elastic Beanstalk Sumo Logic Config

sumo_logic.config

# This will automatically install the Sumo Logic collector on AWS Elastic
# Beanstalk instances. Add this to the .ebextensions folder in your app root
# and edit L24-25 to match your Sumo Logic accessid and accesskey. To add or
# remove tracked files, simply add or remove source hashes to the sources
# array on L36.
packages:
  rpm:
    SumoCollector: https://collectors.sumologic.com/rest/download/rpm/64

services:
  sysvinit:
    collector:
      enabled: true
      ensureRunning: true
      files:
        - /etc/sumo.conf

files:
  "/etc/sumo.conf":
    mode: "000755"
    owner: root
    group: root
    content: |
      accessid=YOURACCESSID
      accesskey=YOURACCESSKEY
      rpmAutoStart=false
      syncSources=/etc/sumo_sources.json

  "/etc/sumo_sources.json":
    mode: "000755"
    owner: root
    group: root
    content: |
      {
        "api.version": "v1",
        "sources": [
          {
            "sourceType": "LocalFile",
            "name": "rails",
            "pathExpression": "/var/log/puma/puma.log"
          },
          {
            "sourceType": "LocalFile",
            "name": "eb activity",
            "pathExpression": "/var/log/eb-activity.log"
          },
          {
            "sourceType": "LocalFile",
            "name": "nginx access",
            "pathExpression": "/var/log/nginx/access.log"
          }
        ]
      }

This will automatically install the Sumo Logic collector on AWS Elastic Beanstalk instances. Add this to the .ebextensions folder in your app root and edit L12 & L13 to match your Sumo Logic accessid and accesskey. Edit the sumo_sources.json (L34-53) to track other logs.

Hey homey, just got pointed to this gist from the sumologic site. Thanks for sharing! Hope everything is going well with you!

Hey @sfkaos! Glad you found it useful man.

This was a helpful starting point. I suggest, however, that we don't encourage people using their real access id and key; especially if checking into github/code management. Instead, we use an S3 bucket.

files:
  "/etc/sumo.conf":
    mode: "000755"
    owner: root
    group: root
    source: https://s3.amazonaws.com/your-bucket-here/your-file-here.txt
    authentication: S3AccessCred

We keep the sumo_sources.json file checked into code to make changes but you could certainly have that file in a bucket as well.

Finally, don't forget to add the authentication:

Resources:
  AWSEBAutoScalingGroup:
    Type: "AWS::AutoScaling::AutoScalingGroup"
    Metadata:
      AWS::CloudFormation::Authentication:
        S3AccessCred:
          type: "S3"
          roleName: "your-role-name-here"
          buckets: "your-bucket-here"

This is assuming your role has the appropriate managed policy assigned to in in IAM. Basically that role needs Get and List S3 bucket access. There's a built in policy for S3 read-only; I suggest using that one.

This might be overkill for some but for my organization we didn't want to put the SL access credentials into the codebase.

Sumologic deprecated /etc/sumo.conf. The config should go here now: /opt/SumoCollector/config/user.properties.

Also, be sure to set "ephemeral=true" or else you'll get a lot of dangling collectors

https://help.sumologic.com/Send_Data/Installed_Collectors/stu_user.properties/Setting_a_Collector_as_Ephemeral

Here's some changes taking into account some of the suggestions here:
https://gist.github.com/JefStat/98891d947a1bbadedcf25921b116e413

• Added ephemeral
• switched to using user.properties
• sumologic logs added to the log collector in beanstalk
• access keys set via environment variable