GitHub Actions

Monitoring GitHub Actions is critical for understanding what causes delays and failures in your CI/CD pipelines. Coralogix supports sending logs, traces, and metrics from completed actions to the platform by providing its own GitHub Action workflow.

The Coralogix GitHub Action is deployed as a separate workflow that runs once all other pipeline workflows are finished. The status of previous workflows doesn't matter – whether they succeeded or failed, the Coralogix GitHub Action will send the telemetry data from them in any case. Once launched, it will gather and send the data to Coralogix via the OpenTelemetry endpoint.

Exported Telemetry

Logs. All logs from target GitHub Actions will be sent to Coralogix and are available for further analysis. Each log record contains multiple attributes, such as task name, task status, and severity, which simplifies filtering and analysis.

Traces. All actions will also be visible in Coralogix as traces. Each executed workflow will be represented as a separate trace with its jobs represented as spans. The workflow's tracing visualization allows you to identify bottlenecks by looking at the jobs' execution time.

Each span will contain multiple attributes, which simplifies filtering and analysis.

Metrics. Each action will also be sent as a counter-type metric, indicating whether it succeeded or failed. There are 3 metrics available:

• github_workflow_failed_job_count_total
• github_workflow_overall_job_count_total
• github_workflow_successful_job_count_total.

All these metrics contain the service name (i.e., repository name) label, so you can see the stats for all repositories as well as distinguish between specific repositories. This might be useful for creating alerts when the number of failed actions reaches a specific threshold.

Installation

Simply add this workflow as a separate file to the .github/workflows directory of the repository you want to monitor. You can name the file however you want – for example, it could be called coralogix.yaml.

name: Export to Coralogix

# Run after all workflows completed
on:
  workflow_run:
    workflows: ['*']
    types: [completed]

permissions: read-all

env:
  # Plugin settings
  GITHUB_DEBUG: false # Set to true for troubleshooting
  ACTION_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  WORKFLOW_RUN_ID: ${{ github.event.workflow_run.id }}
  WORKFLOW_RUN_NAME: ${{ github.event.workflow_run.name }}
  # CX endpoint settings
  OTLP_PROTOCOL: HTTP
  OTEL_EXPORTER_OTLP_ENDPOINT: https://ingress.:443
  OTEL_EXPORTER_OTLP_HEADERS: Authorization=Bearer ${{ secrets.CORALOGIX_API_KEY }}
  GITHUB_CUSTOM_ATTS: '{"service.name":"github", "cx.application.name":"ghactions", "cx.subsystem.name":${{ github.repository }}}'

jobs:
  Coralogix-Exporter:
    name: Coralogix Exporter
    runs-on: ubuntu-latest
    if: ${{ always() }}
    steps:
      - name: Checkout
        uses: actions/checkout@v5 
      - name: Run Coralogix Exporter
        uses: coralogix/OTLP-GitHubAction-Exporter@v3

• The workflow file must be placed in the default branch to run alongside all repository actions in all branches. Before testing this workflow, please make sure it's in the default branch, whether it's main or master.

• Besides adding the workflow file to your repo, you need to configure your Coralogix Send-Your-Data API Token as a secret in your repository and call it CORALOGIX_API_KEY.

• You can set both workflow and secret globally. This will help you smoothly scale this solution instead of copying and pasting across multiple repositories. To use the workflow globally, configure organization-wide required workflows. To use the secret globally, configure organization secrets.

• The exporter uses automatic token authentication by default. For this, you need to ensure that GITHUB_TOKEN has at least read access to the action scope, as provided in this example.

• You can also set Application Name and Subsystem Name dynamically. In this example, we're setting the repository name as the Subsystem Name. You can use your environment variables or GitHub environment variables.

You can also view this example in the Coralogix action's repository.

Required Configuration

All configuration parameters are set as workflow's environment variables.

PARAMETER	DESCRIPTION	SUGGESTED VALUE
OTEL_EXPORTER_OTLP_ENDPOINT	The OTLP endpoint for exporting telemetry data to Coralogix.	https://ingress.:443
OTEL_EXPORTER_OTLP_HEADERS	Used to set Authorization header for OTLP exporter in order to authenticate with Coralogix. If you want to add other headers, enter these in a commas separated, key=value format. It's required to configure your Coralogix Send-Your-Data API Token as a secret in your repository, and call it CORALOGIX_API_KEY	Authorization=Bearer ${{ secrets.CORALOGIX_API_KEY }}
ACTION_TOKEN	GitHub token used for authentication in the workflow. Typically ${{ secrets.GITHUB_TOKEN }}, however a PAT can be used if it has appropriate permissions.	${{ secrets.GITHUB_TOKEN }}
WORKFLOW_RUN_ID	This contains the Workflow Run ID for the workflow that triggered this Workflow.	${{ github.event.workflow_run.id }}
WORKFLOW_RUN_NAME	This contains the Workflow Run Name for the workflow that triggered this Workflow.	${{ github.event.workflow_run.name }}

Optional Configuration

Notes

Send the data to your OTEL Collector

Since the Coralogix GitHub Action uses the OTEL Exporter to send telemetry, you can also send metrics to your OpenTelemetry setup if you want to perform some processing on your logs, metrics, and traces. Depending on your OpenTelemetry setup, you can send the telemetry either to an OTEL Collector or to an OTEL Gateway.

To make it work, you need to:

1. Expose your OpenTelemetry Collector's OTLP Endpoint so that GitHub IP addresses can reach it. We recommend using a separate load balancer for this purpose.
2. Configure Server Authentication on your OpenTelemetry Collector.
3. Configure OTEL_EXPORTER_OTLP_ENDPOINT and OTEL_EXPORTER_OTLP_HEADERS to match your OpenTelemetry endpoint.

Here is an example of configuring an OTLP receiver to serve the endpoint for the Coralogix GitHub Action.

extensions:
  bearertokenauth:
    token: "somerandomtoken"
    filename: "file-containing.token"

receivers:
  otlp:
    protocols:
      http:
        endpoint: myhostname:4318
        auth:
          authenticator: bearertokenauth
        cors:
          allowed_origins:
            - https://github.com
            - https://*.github.com

processors:

exporters:
  # your coralogix exporter
  coralogix:

service:
  extensions: [bearertokenauth]
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [coralogix]

Using Coralogix GitHub Action with GitHub Enterprise Server

You can also use our GitHub Actions integration if you have a GitHub Enterprise Server. To allow GitHub Actions in your enterprise to use public actions from GitHub.com, you can connect your enterprise instance to GitHub Enterprise Cloud. Follow the GitHub documentation to set it up.

Validation

After pushing the workflow file to the default branch, you should see it running in the pipeline of the commit it was pushed under. Check the "Actions" tab to find the workflow's name. Once it's completed, check its status and logs. If it runs successfully, you should start seeing a variety of logs, metrics, and traces being submitted to the Coralogix platform aligned with your configured application and subsystem names. Afterward, you will see the telemetry coming from different branches and different actions in those branches.

If Coralogix Action fails, check the Troubleshooting section below.

Troubleshooting

If the Coralogix Action failed, you should see the root cause in its logs. If you aren't able to identify the root cause of the failure, reach out to Support.

If the Coralogix Action succeeded, but you don't see any logs, metrics, or traces arriving in your Coralogix account, make sure to double-check your workflow configurations.

First and foremost, ensure your endpoint (OTEL_EXPORTER_OTLP_ENDPOINT) and authentication header (OTEL_EXPORTER_OTLP_HEADERS) are set correctly.

Then ensure that your secret CORALOGIX_API_KEY is in the right context and reachable by GitHub. If it's placed in a specific environment, you should set this environment in the workflow. Here is an example of how to do it:

jobs:
  Coralogix-Exporter:
    name: Coralogix Exporter
    # here
    environment: Monitoring
    runs-on: ubuntu-latest
    if: ${{ always() }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run Coralogix Exporter
        uses: coralogix/OTLP-GitHubAction-Exporter@v3

Additional Resources

Support

Need help?

Our world-class customer success team is available 24/7 to walk you through your setup and answer any questions that may come up.

Contact us via our in-app chat or by emailing support@coralogix.com.