eMudhra – Coralogix Full Upgrade Guide

On October 20th, the private keys for 8 intermediate certificate authority (CA) certificates, operated by eMudhra, were compromised. This is an industry-wide issue, so we wish to fully support our customers in ensuring that their systems are as robust and secure as possible.

What is the impact on the Coralogix platform?

There is no impact to Coralogix. Coralogix endpoints do not use eMudhra or emSign certificates. Likewise, any internal Coralogix services do not depend on these certificates, meaning that the internal Coralogix platform has been untouched by these leaked keys. 

Out of an abundance of caution, you can upgrade your integrations with Coralogix to the latest version, as part of your normal update tasks. We have provided recommended guidance for the following integrations. Each component has been coupled with clear guides of what to expect when moving between different versions of these tools. 

At a glance

Component	Priority	Recommended action	Recommended Version	Upgrade Guidance
Kubernetes integration (otel-integration Helm chart)	Low	Upgrade the Helm chart	0.0.362	Click here
OpenTelemetry Collector Contrib	Low	Upgrade the collector	v0.163.2	Click here
Coralogix Operator	Medium	Upgrade	v2.16.0 (FIPS: v2.16.0-fips)	Click here
Coralogix Terraform provider	Medium	Upgrade the provider version	v3.22.0	Click here
Coralogix CLI (cx-cli)	Medium	Re-run the install/update script, or download it from the release page	v0.1.28	Click here
AWS Lambda telemetry extension	Low	Update the layer version on each function	Layer 39	Click here
Supervised collector and supervised eBPF profiler	Low	Upgrade	0.17.0	Click here
CloudWatch Metric Streams transformation Lambda	Low	Refresh the function code (aws lambda update-function-code) or recreate the function; terraform apply alone won’t pick it up	firehose-metrics-transformer.zip (published 23 October 2026)	Click here
Coralogix OpenTelemetry Collector (CDOT)	Low	Upgrade	v0.5.18	Click here
coralogix-aws-shipper	Low	Update the CloudFormation/SAR stack, or set source_code_version in Terraform. GovCloud/FIPS: choose to upgrade or stay	1.4.20. The FIPS build uses a module pending NIST validation	Click here
AWS Lambda auto-instrumentation layers (Python, Node.js, Java)	Low	Update the layer version on each function	Python: Layer 36, Node.js: Layer 43, Java: Layer 20	Click here

Upgrading Coralogix components: what changes

Kubernetes integration (otel-integration Helm chart): upgrade to 0.0.362

The Helm chart that installs OpenTelemetry Collectors in your Kubernetes cluster to send logs, metrics, traces and profiles to Coralogix. Version 0.0.362 runs OpenTelemetry Collector v0.163.2.

Docs: Kubernetes observability using OpenTelemetry, Advanced configuration, Chart upgrade notes, Span metrics

Check your current version

helm list -A | grep otel-integration

The CHART column shows your version, for example otel-integration-0.0.350.

At a glance

Your version	Will anything stop working?	Will your data look different?
0.0.360 to 0.0.361	Only if you wrote your own supervisor configuration	No
0.0.351 to 0.0.359	Only if you set certain feature flags	Yes: some database and Prometheus fields
0.0.344 to 0.0.350	Only if you customized Kubernetes attribute settings	Yes: Kubernetes CPU values and some metric names
0.0.326 to 0.0.343	No	Yes: span metrics and some collector metrics
0.0.304 to 0.0.325	Possibly: memory use and pod scheduling	Yes: database queries are masked, Zipkin field names
0.0.271 to 0.0.303	No	Yes: Azure platform values
0.0.239 to 0.0.270	Only if you turned off API server metrics	Yes: some labels removed
0.0.213 to 0.0.238	No	Yes: span metric names and span names
0.0.164 to 0.0.212	Yes: image location and values file layout	Yes: Prometheus field names

OpenTelemetry Collector Contrib: upgrade to v0.163.2

The upstream OpenTelemetry Collector Contrib distribution, for customers who run it themselves to send data to Coralogix. If you use the Kubernetes integration Helm chart, the chart manages this for you; follow the Kubernetes integration section instead.

Docs: OpenTelemetry using Docker, v0.163.2 release, Contrib changelog

Check your current version

# Binary install
otelcol-contrib --version
# Kubernetes
kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | grep opentelemetry-collector-contrib | sort -u
# Docker
docker ps --format '{{.Image}}' | grep opentelemetry-collector-contrib

The image tag or the --version output is your version.

At a glance

Your version	Will anything stop working?	Will your data look different?
v0.163.0 to v0.163.1	No	No
v0.162.x	Only if you use the OpAMP supervisor or certain receiver settings	Yes: SQL Server metrics
v0.160.x to v0.161.x	Only if you set certain feature flags	Yes: Kubernetes CPU and label names, Prometheus labels
v0.157.x to v0.159.x	Yes, if your configuration uses removed settings	Yes: Kubernetes collector health metrics
v0.152.x to v0.156.x	Possibly: transform and filter error handling, duplicate span metric dimensions	Yes: per-CPU host metrics, metric units, collector health metrics
v0.146.x to v0.151.x	Only if you use removed Prometheus receiver settings	Yes: span metrics, Zipkin and Azure field names
v0.140.x to v0.145.x	Only if you use removed settings	Yes: Kubernetes volume fields, GCP field names
v0.122.x to v0.139.x	Yes, if you use the routing processor or removed exporter settings	Yes: Prometheus and Kubernetes CPU metric names

Coralogix Operator: upgrade to v2.16.0 (FIPS build: v2.16.0-fips)

A Kubernetes operator that creates and manages Coralogix alerts, dashboards, rule groups, TCO policies, SLOs and other resources from Kubernetes manifests. The FIPS build has the same changes.

Docs: Coralogix Operator

Check your current version

kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | grep coralogix-operator | sort -u

The image tag is your version, for example coralogix-operator:v2.12.0.

At a glance

Your version	Will anything stop working?	Will your Coralogix resources change?
v2.13.0 to v2.15.2	Only ConfigurationGroup (Preview) manifests	Groups without a custom role start syncing
v2.5.0 to v2.12.0	Only if the legacy cx-operator is installed	No
v2.1.0 to v2.4.1	Yes, if your network allowlist uses old API addresses	Some dashboards may stop syncing
v2.0.0 to v2.0.5	Yes, if you use long region names	Some alerts may be turned off; duplicates possible
v1.0.0 to v1.1.2	Yes: GlobalRouter and SLO manifests	A new router may be created
v0.x	Yes: old alert manifests	No

Coralogix Terraform provider: upgrade to v3.22.0

The Terraform provider for managing Coralogix alerts, dashboards, parsing rules, TCO policies, SLOs and other resources as code.

Docs: Coralogix Terraform provider, Alerts migration guide, Notification routing

Check your current version

Run this in your Terraform directory:

terraform version

The line provider registry.terraform.io/coralogix/coralogix shows your version. You can also read the version under coralogix/coralogix in .terraform.lock.hcl.

At a glance

Your version	Will terraform plan fail?	Will terraform apply change your Coralogix resources?
v3.21.x	No	Only if you removed descriptions
v3.18.0 to v3.20.x	Yes, if you use coralogix_fleet_configuration_group	Yes: some folders and routers can be replaced
v3.11.0 to v3.17.x	Possibly: alert labels and TCO policies	Yes: alert notification routing can change
v3.5.0 to v3.10.x	Possibly: rule group order	Dashboards stop being recreated on edit
v3.0.0 to v3.4.x	No	Yes: alert notification settings can be cleared
v2.x	Possibly: alert filters and routers	No, alerts keep their IDs
v1.x	Yes: alerts must be rewritten	Yes: alerts are re-imported

Coralogix CLI (cx-cli): upgrade to v0.1.28

The cx command-line tool for querying data and managing Coralogix from a terminal or script. The install script replaces the cx program only. Your settings in ~/.cx are kept.

Docs: cx-cli release notes, Install guide, v0.1.28 release

Check your current version

cx --version

At a glance

Your version	Will commands or scripts break?	Will results look different?
v0.1.26 to v0.1.27	No	No
v0.1.19 to v0.1.25	Only scripts that read cx infra or suppression rule output	Yes: some JSON output
v0.1.14 to v0.1.18	Only cx init flags	No
v0.1.11 to v0.1.13	Scripts that check exit codes	No
v0.1.5 to v0.1.10	Yes: cx incidents is removed	Yes: some JSON output
v0.1.2 to v0.1.4	Yes: some commands removed	Yes: queries search a different data tier
v0.1.1	Yes: scripts that change resources	No

AWS Lambda telemetry extension: upgrade to layer 39

A Lambda layer that sends logs, metrics and traces from your Lambda functions to Coralogix. Layer 39 contains exporter version 1.3.0.

Docs: AWS Lambda telemetry exporter, Changelog

Check your current version

aws lambda get-function-configuration --function-name <function> --query 'Layers[].Arn'

In an ARN that contains coralogix-aws-lambda-telemetry-exporter, the number after the last : is your layer version. An ARN that contains coralogix-extension is the legacy layer.

At a glance

Your layer	Will anything stop working?	Will your data look different?
37 to 38	No	No
34 to 36	No	Data rejected for exceeding quota is not resent
31 to 33	No	No
29 to 30	Only if you send to your own collector (CX_OTEL_URL)	No
23 to 28	No	Yes: metrics and spans
18 to 22	No	Yes: more logs delivered
Legacy coralogix-extension	Yes: settings must change	Yes: names and log format

Supervised collector and supervised eBPF profiler: upgrade to 0.17.0

Container images that run the OpenTelemetry Collector or the eBPF profiler under a supervisor, so Coralogix Fleet Management can configure them remotely. Version 0.17.0 runs collector and profiler v0.163.2.

Docs: Fleet Management, Continuous Profiling setup

Check your current version

# Kubernetes
kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | grep supervised | sort -u
# Docker
docker ps --format '{{.Image}}' | grep supervised

The image tag is your version, for example coralogix-otel-supervised-collector:0.15.0.

At a glance

Your version	Will anything stop working?	Will your data look different?
All versions	Yes, if your supervisor configuration has reports_remote_config: true	No
Collector 0.13.0 to 0.16.0	Only if you use renamed settings	Yes: some SQL Server and Kubernetes CPU metrics
Collector 0.1.0 to 0.12.0	Only if you use renamed settings	Yes: per-CPU host metrics and some metric units
Profiler 0.7.0 to 0.16.0	Yes, if your configuration uses renamed settings	Off-CPU profiles need a new setting
Profiler 0.1.0 to 0.6.0	Yes, on Linux kernels older than 5.10	No

CloudWatch Metric Streams transformation Lambda: update firehose-metrics-transformer.zip

A Lambda function that converts CloudWatch metrics streamed through Amazon Data Firehose before they are sent to Coralogix.

Docs: AWS CloudWatch metrics

Check your current version

aws lambda get-function-configuration --function-name <function> --query 'LastModified'

If the function code was last updated before 23 October 2026, it runs the old package.

Coralogix OpenTelemetry Collector (CDOT): upgrade to v0.5.18

CDOT is Coralogix’s build of the OpenTelemetry Collector Contrib distribution, with extra components for Amazon ECS, that collects your logs, metrics and traces and sends them to Coralogix.

Docs: AWS ECS-EC2 using OpenTelemetry, AWS ECS-EC2 (Windows) using OpenTelemetry

Check your current version

Look at the image tag CDOT runs from. These commands only read.

# Amazon ECS
aws ecs describe-task-definition --task-definition <your-task-definition> --query 'taskDefinition.containerDefinitions[].image'
# Docker host (Linux or Windows)
docker ps --format '{{.Image}}' | grep coralogix-otel
# Kubernetes
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep coralogix-otel

• Linux: coralogixrepo/coralogix-otel-collector:v0.5.17 means you run v0.5.17. The same image is mirrored as cgx.jfrog.io/coralogix-docker-images/otel-collector-linux.
• Windows: the tag ends in -windowsserver-1809 or -windowsserver-2022, for example coralogixrepo/coralogix-otel-collector:v0.5.17-windowsserver-2022. The fixed tags are v0.5.18-windowsserver-1809 and v0.5.18-windowsserver-2022. The mirror is cgx.jfrog.io/coralogix-docker-images/otel-collector-windows.
• Supervised CDOT (cgx.jfrog.io/coralogix-docker-images/coralogix-otel-supervised-cdot, used by ECS-EC2 supervised mode): the tag is the supervised image version, not the CDOT version. v0.17.1 contains CDOT v0.5.18. v0.16.0 and v0.17.0 contain v0.5.17. v0.0.4 to v0.15.0 contain v0.5.12. v0.0.1 to v0.0.3 contain v0.5.9. Move to v0.17.1 and read the band for the CDOT version you have now.
• Use the image tag, not the collector’s --version output. On some releases the two do not match (v0.5.10 and v0.5.11 report 0.5.9).

At a glance

Your version	Will anything stop working?	Will your data look different?
v0.5.13 to v0.5.17	Only if you use the Mezmo exporter, the Wavefront receiver, the OTTL Base64Decode function or a removed feature gate. Supervised CDOT users must also check one Supervisor setting.	Slightly. Some Prometheus labels and scope attributes, and OTTL set with empty values.
v0.5.0 to v0.5.12	Yes, if your config uses a component or setting removed in v0.5.1 to v0.5.13, including the old top-level endpoint on the Coralogix exporter.	Yes. Host CPU metrics are summed across CPUs, span metrics gain a label, and Prometheus start times, Zipkin attribute names and collector self-metric names change.
v0.4.0 to v0.4.2	Yes, if you use the Coralogix exporter batcher setting or service::telemetry::address.	Yes. Prometheus scraping moves to Prometheus 3 naming, some Prometheus resource attributes are renamed, and ECS CPU metrics gain units.
v0.3.0 to v0.3.1	Yes, if you use the memory_ballast extension or the Instana exporter.	Yes. Default span metric names change, and the container log parser drops the original time field.
v0.2.0 to v0.2.13	Yes. Several components are removed, $VAR environment syntax stops working, and OTLP receivers listen on localhost unless you set an endpoint.	Yes. process.cpu.utilization is divided by CPU count, and collector self-metrics gain an otelcol_ prefix.
v0.1.0 to v0.1.3	Yes, if you use the Jaeger, Jaeger Thrift HTTP or Parquet exporters, or the prometheus_exec receiver.	Span metric histograms stop carrying exemplars by default.

coralogix-aws-shipper: upgrade to 1.4.20

The Coralogix AWS Shipper is an AWS Lambda function that collects logs from AWS services such as S3, CloudTrail, VPC Flow Logs, CloudWatch, SNS, SQS, Kinesis, MSK, Kafka and ECR image scans (and, optionally, CloudWatch metrics and Transaction Search traces) and sends them to Coralogix. Please note too that the FIPS build contains a cryptographic module that is not yet approved by NIST.

Docs: Forward AWS Logs via Lambda Shipper, Forward AWS Logs via Lambda Shipper with Terraform

Check your current version

These commands only read configuration.

# CloudFormation or SAR stack
STACK=<your-stack-name>
# SAR installs: AWS tags the stack with the application version
aws cloudformation describe-stacks --stack-name "$STACK" \
  --query "Stacks[0].Tags[?Key=='serverlessrepo:semanticVersion'].Value" --output text
# Quick Create and GovCloud stacks: read the version from the deployed template
aws cloudformation get-template --stack-name "$STACK" --query TemplateBody --output text \
  | grep -E "SemanticVersion|Version: [0-9]|coralogix-aws-shipper-.*[0-9]\.zip"
# GovCloud only: a release you chose yourself shows here
aws cloudformation describe-stacks --stack-name "$STACK" \
  --query "Stacks[0].Parameters[?ParameterKey=='LambdaCodeKey'].ParameterValue" --output text
# Terraform: the module variable that pins the release
grep -rn "source_code_version" --include=*.tf .

The template has no version parameter. In the template, the version is SemanticVersion (commercial template) or the Release mapping Version (GovCloud template). In GovCloud, a non-empty LambdaCodeKey such as coralogix-aws-shipper-arm64-1.4.19.zip overrides that default. In Terraform, an empty or missing source_code_version means the module deployed the latest published release at the time.

Items below show the version that introduced them in brackets. An item applies to you if your current version is lower than that number.

At a glance

Your version	Will anything stop working?	Will your data look different?
1.4.0 to 1.4.19	Yes, if your runtime is set to provided.al2, or if a traces stack still has an SQS or SNS ARN set.	Yes, for Kinesis and SQS with dynamic names, and for metrics with CustomMetadata.
1.3.0 to 1.3.15	Possibly. The default ingress hostname changes, which matters if you filter outbound traffic by hostname.	Yes. Everything above, plus a missing metadata key now gives unknown-application or unknown-subsystem.
1.1.0 to 1.2.0	Same as above.	Same as above.
1.0.0 to 1.0.16	Yes, if your application or subsystem name uses $.field or {{s3_key.N}}.	Yes. Everything above, plus fixes for duplicate CloudWatch logs and for CloudWatch logs carried over Kinesis.
0.0.x (beta)	Same as 1.0.0.	Same as 1.0.0.

AWS Lambda auto-instrumentation layers: upgrade to Python layer 36, Node.js layer 43, Java layer 20

The coralogix-<language>-wrapper-and-exporter-<arch> Lambda layers combine the Coralogix OpenTelemetry auto-instrumentation wrapper for Python, Node.js or Java with the Coralogix AWS Lambda telemetry exporter, so one layer gives you traces, metrics and logs without code changes.

Docs: Lambda auto-instrumentation, Python changelog, Node.js changelog, Java changelog, Telemetry exporter changelog

Check your current version

Run this for each function. It only reads configuration.

aws lambda get-function-configuration --function-name <function-name> \
  --query 'Layers[].Arn' --output text

Look for an ARN like arn:aws:lambda:<region>:625240141681:layer:coralogix-python-wrapper-and-exporter-x86_64:35. The layer name tells you the language (python, nodejs or java) and architecture (x86_64 or arm64). The number after the last colon is your layer version. If you only see coralogix-aws-lambda-telemetry-exporter-<arch>, you run the standalone exporter, not these layers. Upgrading the standalone exporter to layer 39 does not update these layers. For container image functions, the version is the tag on coralogixrepo/coralogix-<language>-wrapper-and-exporter:<version> in your Dockerfile.

To upgrade, replace the layer ARN with the same name at the target version. No release note changes AWS_LAMBDA_EXEC_WRAPPER=/opt/otel-handler, CX_DOMAIN, CX_API_KEY or CX_REPORTING_STRATEGY. Items below show the layer that introduced them in brackets. An item applies to you if your current layer is lower than that number.

At a glance

Your layer	Will anything stop working?	Will your data look different?
Python 35	Only on Amazon Linux 1 runtimes.	No data change is listed.
Python 32 to 34	Only on Amazon Linux 1 runtimes.	Possibly. Python instrumentation packages are updated.
Python 25 to 31	Only on Amazon Linux 1 runtimes.	Possibly. Python instrumentation packages are updated.
Python 16 to 24	Only on Amazon Linux 1 runtimes.	Yes. SQS trigger links are fixed and new warm-up spans appear.
Python 15 and earlier	Yes, if you send to your own endpoint with CX_OTEL_URL.	Yes. Early spans appear and OpenTelemetry metrics are reduced by default.
Node.js 42	Only on Amazon Linux 1 runtimes.	Possibly. Node.js instrumentation libraries are updated.
Node.js 36 to 41	Yes, on Node.js 20.	Possibly. Node.js instrumentation libraries are updated.
Node.js 26 to 35	Yes, on Node.js 20.	Yes. New SNS, Kinesis and Step Functions trigger spans.
Node.js 21 to 25	Yes, on Node.js 20.	Yes. Everything above, plus the faas.coldstart attribute and warm-up spans.
Node.js 20 and earlier	Yes, on Node.js 20, or if you send to your own endpoint with CX_OTEL_URL.	Yes. Early spans appear and OpenTelemetry metrics are reduced by default.
Java 18 to 19	Only on Amazon Linux 1 runtimes.	Possibly. The Java agent and SDK are updated.
Java 15 to 17	Only on Amazon Linux 1 runtimes.	Yes. Six new trigger types produce trigger spans.
Java 9 to 14	Only on Amazon Linux 1 runtimes.	Yes. Same as above, plus warm-up spans.
Java 8 and earlier	Yes, if you send to your own endpoint with CX_OTEL_URL.	Yes. Early spans appear and OpenTelemetry metrics are reduced by default.