---
title: "Configure L7 logs"
description: "Deploy Envoy and aggregate Calico Cloud L7 logs to monitor HTTP traffic patterns between application workloads on connected clusters."
product: "Calico Cloud"
version: "v23.0.1"
section: "Observability"
canonical_url: "https://docs.tigera.io/calico-cloud/observability/elastic/l7/configure"
---

# Configure L7 logs

> **WARNING:** L7 logging with Envoy is deprecated and will be removed in an upcoming release. Calico Cloud is moving to L7 observability based on [Istio Ambient Mode](https://docs.tigera.io/calico-cloud/compliance/istio/about-istio-ambient.md).

## Big picture

Deploy Envoy and use Calico Cloud L7 logs to monitor application activity.

## Value

Just like L3/4 Calico Cloud logs, platform operators and development teams want visibility into L7 logs to see how applications are interacting with each other. Calico Cloud flow logs only display which workloads are communicating with each other, not the specific request details. Calico Cloud provides visibility into L7 traffic without the need for a service mesh.

L7 logs are also key for detecting anomalous behaviors like attempts to access applications, restricted URLs, and scans for particular URLs.

## Concepts

### About L7 logs

L7 logs capture application interactions from HTTP header data in requests. Data shows what is actually sent in communications between specific pods, providing more specificity than flow logs. (Flow logs capture data only from connections for workload interactions).

Calico Cloud collects L7 logs by sending the selected traffic through an Envoy proxy.

L7 logs are visible in the web console, service graph, in the HTTP tab.

## Before you begin

**Not supported**

- GKE

### Limitations

- L7 log collection is not compatible with a service mesh such as Istio.
- L7 log collection is not supported for host-networked client pods.
- L7 log collection is supported only on Kubernetes 1.29 and later.

> **INFO:** When you enable L7 log collection for a deployment, all of that deployment's pods will restart. Selecting and deselecting traffic for L7 log collection may result in disruptions for active connections.

> **SECONDARY:** L7 logs require a minimum of 1 additional GB of log storage per node, per one-day retention period.

## Configure Felix for log data collection

1. Configure L7 log aggregation, retention, and reporting.

   For help, see [Felix Configuration documentation](https://docs.tigera.io/calico-cloud/reference/component-resources/node/felix/configuration.md).

## Configure L7 logs

In this step, you will configure L7 logs, select logs for collection, and test the configuration.

### Configure the ApplicationLayer resource for L7 logs

1. Create or update the [ApplicationLayer](https://docs.tigera.io/calico-cloud/reference/installation/api.md#applicationlayer) resource named, `tigera-secure`.

   Example:

   ```bash
   kubectl apply -f - <<EOF
   apiVersion: operator.tigera.io/v1
   kind: ApplicationLayer
   metadata:
     name: tigera-secure
   spec:
     # log collection is implemented via sidecar
     sidecarInjection: Enabled
     # the following configures the log collection and aggregation behaviour
     logCollection:
       collectLogs: Enabled
       logIntervalSeconds: 5
       logRequestsPerInterval: -1
   EOF
   ```

   Read more about the log collection specification [here](https://docs.tigera.io/calico-cloud/reference/installation/api.md#logcollector).

   Applying this resource creates an `l7-log-collector` daemonset in `calico-system` namespace.

2. Wait for the Tigera APIServer deployment and Log collection daemonset to progress to ready.

   ```bash
   kubectl rollout status -n calico-system deployment/calico-apiserver --timeout=120s
   kubectl rollout status -n calico-system ds/l7-log-collector --timeout=120s
   ```

### Quickstart: enable log collection on an example app

1. Install Google Microservices Demo

   ```bash
   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/refs/heads/main/release/kubernetes-manifests.yaml
   ```

   without the `-n <namespace>` flag, it is going to be installed in the `default` namespace. if you wish to install in a different namespace, specify the `-n <namespace>` flag on all other commands in this tutorial from this point on.

2. Patch the `frontend` application deployment to start collecting L7 logs for this application

   ```bash
   kubectl patch deployment frontend -p '{"spec":{"template":{"metadata":{"labels":{"applicationlayer.projectcalico.org/sidecar":"true"},"annotations":{"applicationlayer.projectcalico.org/logging":"Enabled"}}}}}'
   ```

   The above command applies the following patch:

   1. ensures pods in your `frontend` deployment pod template spec has the label `applicationlayer.projectcalico.org/sidecar: true`
   2. ensures pods in your `frontend` deployment pod template spec has the following annotations:

   - `applicationlayer.projectcalico.org/logging: Enabled`

   Deployment pods will then be expected to restart. Monitor its progress with:

   ```bash
   kubectl rollout status deployment frontend
   ```

   [Google Microservices Demo](https://github.com/GoogleCloudPlatform/microservices-demo) includes a load generator. L7 logs should now start displaying log entries that can be viewed via [various UIs](#view-l7-logs-in-the-web-console)

   Alternatively, it is possible to test your configuration [manually](#test-your-configuration).

3. To disable L7 log collection, reverse the above patch with the following command.

   ```bash
   kubectl patch deployment frontend --type='json' -p '[{"op":"remove","path":"/spec/template/metadata/labels/applicationlayer.projectcalico.org~1sidecar"},{"op":"remove","path":"/spec/template/metadata/annotations/applicationlayer.projectcalico.org~1logging"}]'
   ```

### Test your configuration

1. Identify the path to access your cluster. Where `<path>` can be:

   - Public address of your cluster/service or
   - Cluster IP of your application's service (if testing within the cluster)

2. `curl` your service with a command similar to the following. You will see `Server` header as `envoy`.

   ```bash
   curl --head <path to access service>:<optional port>/<path>
   ```

## View L7 logs in the web console

### Service Graph

To view L7 logs in Service Graph:

1. In the web console left navbar, click **Service Graph**.

2. In the bottom pane you will see L7 logs in the HTTP tab.

   ![l7-logs](https://docs.tigera.io/assets/images/l7-logs-cad7cc9111742ad666c84646eb7523f4.png)