{"id":993,"date":"2026-05-18T03:48:42","date_gmt":"2026-05-18T03:48:42","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=993"},"modified":"2026-05-18T03:48:43","modified_gmt":"2026-05-18T03:48:43","slug":"datadog-application-error-tracking-in-eks-using-datadog-dogstatsd-apm-logs-and-error-tracking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/datadog-application-error-tracking-in-eks-using-datadog-dogstatsd-apm-logs-and-error-tracking\/","title":{"rendered":"Datadog: Application Error Tracking in EKS using Datadog, DogStatsD, APM, Logs, and Error Tracking"},"content":{"rendered":"\n

Master Guide: Application Error Tracking in EKS using Datadog, DogStatsD, APM, Logs, and Error Tracking<\/h1>\n\n\n\n

First, tiny naming correction: it is DogStatsD<\/strong>, not DogStashD. DogStatsD is Datadog\u2019s StatsD-compatible custom metrics service. It is excellent for counting application errors, but it is not a full Sentry replacement by itself<\/strong>. For Sentry-like error debugging, you should combine:<\/p>\n\n\n\n

DogStatsD metrics\n+ Application logs with stack traces\n+ Datadog APM traces\n+ Datadog Error Tracking\n+ Kubernetes \/ EKS metadata\n+ Unified service tagging\n<\/code><\/pre>\n\n\n\n
This is the best implementation pattern for your app running inside containers\/pods on EKS<\/strong>.<\/p>\n\n\n\n
\n\n\n\n
1. What we are trying to build<\/h1>\n\n\n\n
The target outcome is:<\/p>\n\n\n\n
Application error happens\n        \u2193\nDatadog captures error count, log, trace, stack trace\n        \u2193\nDatadog links it to service, env, version\n        \u2193\nDatadog adds Kubernetes context\n        \u2193\nYou can identify the exact pod\/container\/deployment\/node\n<\/code><\/pre>\n\n\n\n
Final relationship should look like this:<\/p>\n\n\n\n
Error Issue\n  \u251c\u2500\u2500 service: checkout-api\n  \u251c\u2500\u2500 env: prod\n  \u251c\u2500\u2500 version: 1.8.4\n  \u251c\u2500\u2500 error.type: PaymentTimeoutException\n  \u251c\u2500\u2500 endpoint: \/api\/checkout\n  \u251c\u2500\u2500 kube_namespace: prod\n  \u251c\u2500\u2500 kube_deployment: checkout-api\n  \u251c\u2500\u2500 pod_name: checkout-api-7c9d8f98c9-xz2lp\n  \u251c\u2500\u2500 container_name: checkout-api\n  \u251c\u2500\u2500 node: ip-10-0-12-25\n  \u2514\u2500\u2500 trace_id \/ log correlation\n<\/code><\/pre>\n\n\n\n
Datadog\u2019s unified service tagging is built around the standard env<\/code>, service<\/code>, and version<\/code> tags, which are used to correlate metrics, traces, logs, containers, and deployment versions. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
\n\n\n\n
2. High-level architecture<\/h1>\n\n\n\n
flowchart TD\n    U[User \/ Client Request] --> ING[Ingress \/ ALB \/ API Gateway]\n    ING --> SVC[Kubernetes Service]\n    SVC --> POD[Application Pod in EKS]\n\n    POD --> APP[Application Container]\n\n    APP -->|DogStatsD custom error metrics| DSD[Datadog Agent DogStatsD]\n    APP -->|APM traces and exceptions| APM[Datadog Agent APM Receiver]\n    APP -->|stdout\/stderr structured logs| LOGS[Kubernetes Node Log Files]\n\n    LOGS --> AGENT[Datadog Agent DaemonSet]\n    DSD --> AGENT\n    APM --> AGENT\n\n    KUBE[Kubernetes API \/ Kubelet Metadata] --> AGENT\n    CLUSTER[Datadog Cluster Agent] --> AGENT\n\n    AGENT --> DD[Datadog Platform]\n\n    DD --> METRICS[Metrics Explorer \/ Dashboards]\n    DD --> LOGEXP[Logs Explorer]\n    DD --> TRACE[APM Traces \/ Service Map]\n    DD --> ERR[Error Tracking]\n    DD --> MON[Monitors \/ Alerts]\n\n    ERR --> RCA[Root Cause Analysis]\n    TRACE --> RCA\n    LOGEXP --> RCA\n    METRICS --> RCA\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
3. Sentry to Datadog mapping<\/h1>\n\n\n\n
Sentry capability<\/th>Datadog equivalent<\/th><\/tr><\/thead>
Error issue grouping<\/td>Datadog Error Tracking<\/td><\/tr>
Stack trace<\/td>APM error span or structured error log<\/td><\/tr>
Release\/version tracking<\/td>version<\/code> tag<\/td><\/tr>
Environment<\/td>env<\/code> tag<\/td><\/tr>
Project\/service<\/td>service<\/code> tag<\/td><\/tr>
Error count<\/td>DogStatsD custom metric<\/td><\/tr>
Request trace<\/td>Datadog APM<\/td><\/tr>
Breadcrumb-style context<\/td>Logs, trace spans, custom tags<\/td><\/tr>
Alert on new error<\/td>Error Tracking monitor<\/td><\/tr>
Alert on error volume<\/td>Metric monitor or APM monitor<\/td><\/tr>
Find pod\/container<\/td>Kubernetes tags from Datadog Agent<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
DogStatsD is useful for custom error counters<\/strong>, but Error Tracking, logs, and APM are what give you the Sentry-like debugging experience.<\/p>\n\n\n\n
\n\n\n\n
4. Recommended implementation model<\/h1>\n\n\n\n
Use four data streams together:<\/p>\n\n\n\n
flowchart LR\n    A[Application Error] --> B[DogStatsD Metric]\n    A --> C[Structured Error Log]\n    A --> D[APM Trace \/ Span Error]\n    A --> E[Kubernetes Metadata]\n\n    B --> F[Dashboards and Metric Alerts]\n    C --> G[Log Search and Error Tracking]\n    D --> H[Trace Debugging and Service Map]\n    E --> I[Pod \/ Container \/ Deployment \/ Node Relationship]\n\n    F --> J[Datadog Incident View]\n    G --> J\n    H --> J\n    I --> J\n<\/code><\/pre>\n\n\n\n
Data type<\/th>Purpose<\/th>Example<\/th><\/tr><\/thead>
DogStatsD metric<\/td>Count and alert<\/td>app.error.count<\/code><\/td><\/tr>
Error log<\/td>Stack trace and message<\/td>JSON log with error.stack<\/code><\/td><\/tr>
APM trace<\/td>Request path and dependency failure<\/td>\/checkout<\/code> \u2192 payment-service<\/code> timeout<\/td><\/tr>
Kubernetes metadata<\/td>Pod\/container relationship<\/td>pod_name<\/code>, kube_deployment<\/code>, kube_namespace<\/code><\/td><\/tr>
Error Tracking issue<\/td>Group similar errors<\/td>PaymentTimeoutException<\/code> grouped as one issue<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Datadog Error Tracking groups errors into issues and can alert on new, regressed, or high-impact errors. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
\n\n\n\n
5. Install Datadog Agent in EKS<\/h1>\n\n\n\n
Datadog supports installation through Datadog Operator<\/strong>, Helm<\/strong>, or manual DaemonSet. Datadog currently recommends the Operator for Kubernetes because it reduces misconfiguration risk, but Helm is also a very common production approach. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
For EKS, the standard model is:<\/p>\n\n\n\n
Datadog Agent = DaemonSet\nDatadog Cluster Agent = Deployment\nApplication Pod sends logs\/traces\/metrics to local node Agent\n<\/code><\/pre>\n\n\n\n
5.1 Create namespace and secret<\/h2>\n\n\n\n
kubectl create namespace datadog\n\nkubectl -n datadog create secret generic datadog-secret \\\n  --from-literal api-key=\"$DD_API_KEY\"\n<\/code><\/pre>\n\n\n\n
5.2 Example datadog-values.yaml<\/code><\/h2>\n\n\n\n
This is a practical production-style baseline for EKS application error tracking:<\/p>\n\n\n\n
targetSystem: linux\n\ndatadog:\n  apiKeyExistingSecret: datadog-secret\n\n  # Example: datadoghq.com, datadoghq.eu, us3.datadoghq.com, us5.datadoghq.com, ap1.datadoghq.com\n  site: datadoghq.com\n\n  clusterName: eks-prod-apne1-01\n\n  kubeStateMetricsCore:\n    enabled: true\n\n  collectEvents: true\n\n  logs:\n    enabled: true\n    containerCollectAll: true\n\n  apm:\n    socketEnabled: true\n    portEnabled: false\n\n  dogstatsd:\n    originDetection: true\n    useSocketVolume: true\n    socketPath: \/var\/run\/datadog\/dsd.socket\n    tagCardinality: orchestrator\n\n  tags:\n    - cloud:aws\n    - platform:eks\n    - owner:devops\n\nclusterAgent:\n  enabled: true\n  admissionController:\n    enabled: true\n    mutateUnlabelled: false\n\nagents:\n  containers:\n    agent:\n      resources:\n        requests:\n          cpu: 200m\n          memory: 256Mi\n        limits:\n          memory: 512Mi\n<\/code><\/pre>\n\n\n\n
Important notes:<\/p>\n\n\n\n
logs.enabled<\/code> and containerCollectAll<\/code> allow the Agent to collect container logs. Datadog\u2019s Kubernetes log collection docs show enabling features.logCollection.enabled<\/code> and containerCollectAll<\/code> with the Operator; the Helm values above express the same intent for Helm-based installs. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
dogstatsd.originDetection<\/code> helps the Agent identify which container\/pod emitted DogStatsD metrics. Datadog documents that DogStatsD origin detection can tag metrics with the same pod tags as Autodiscovery metrics, but the Agent-side origin detection is not enabled by default unless configured. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
apm.socketEnabled<\/code> and dogstatsd.useSocketVolume<\/code> use Unix Domain Socket communication. For Kubernetes APM, Datadog supports UDS, host IP, or Kubernetes service communication, and recommends UDS for trace submission. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
5.3 Install or upgrade Agent<\/h2>\n\n\n\n
helm upgrade --install datadog-agent datadog\/datadog \\\n  -n datadog \\\n  -f datadog-values.yaml\n<\/code><\/pre>\n\n\n\n
Verify:<\/p>\n\n\n\n
kubectl -n datadog get pods\nkubectl -n datadog get ds\nkubectl -n datadog get deploy\n<\/code><\/pre>\n\n\n\n
Expected resources:<\/p>\n\n\n\n
datadog-agent DaemonSet\ndatadog-cluster-agent Deployment\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
6. Add unified service tags to your application<\/h1>\n\n\n\n
This is the most important part for relationship-building.<\/p>\n\n\n\n
Every application Deployment should have:<\/p>\n\n\n\n
env\nservice\nversion\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: checkout-api\n  namespace: prod\n  labels:\n    tags.datadoghq.com\/env: \"prod\"\n    tags.datadoghq.com\/service: \"checkout-api\"\n    tags.datadoghq.com\/version: \"1.8.4\"\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: checkout-api\n  template:\n    metadata:\n      labels:\n        app: checkout-api\n        tags.datadoghq.com\/env: \"prod\"\n        tags.datadoghq.com\/service: \"checkout-api\"\n        tags.datadoghq.com\/version: \"1.8.4\"\n      annotations:\n        admission.datadoghq.com\/enabled: \"true\"\n        ad.datadoghq.com\/checkout-api.logs: '[{\"source\":\"java\",\"service\":\"checkout-api\"}]'\n    spec:\n      containers:\n        - name: checkout-api\n          image: myrepo\/checkout-api:1.8.4\n          env:\n            - name: DD_ENV\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.labels['tags.datadoghq.com\/env']\n\n            - name: DD_SERVICE\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.labels['tags.datadoghq.com\/service']\n\n            - name: DD_VERSION\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.labels['tags.datadoghq.com\/version']\n\n            - name: DD_ENTITY_ID\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.uid\n\n            - name: DD_TRACE_AGENT_URL\n              value: \"unix:\/\/\/var\/run\/datadog\/apm.socket\"\n\n            - name: DOGSTATSD_SOCKET\n              value: \"\/var\/run\/datadog\/dsd.socket\"\n\n          volumeMounts:\n            - name: datadog-socket\n              mountPath: \/var\/run\/datadog\n              readOnly: true\n\n      volumes:\n        - name: datadog-socket\n          hostPath:\n            path: \/var\/run\/datadog\n<\/code><\/pre>\n\n\n\n
Datadog\u2019s Kubernetes unified service tagging documentation recommends applying tags.datadoghq.com\/env<\/code>, tags.datadoghq.com\/service<\/code>, and tags.datadoghq.com\/version<\/code> labels at the Deployment and pod template levels, and exposing them to the container as DD_ENV<\/code>, DD_SERVICE<\/code>, and DD_VERSION<\/code>. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
\n\n\n\n
7. Understand the exact error-tracking flow<\/h1>\n\n\n\n
sequenceDiagram\n    participant User\n    participant App as App Container\n    participant DogStatsD as DogStatsD Socket\n    participant Logs as Container Logs\n    participant APM as APM Tracer\n    participant Agent as Datadog Agent\n    participant DD as Datadog\n    participant ET as Error Tracking\n\n    User->>App: API request\n    App->>App: Exception occurs\n\n    App->>DogStatsD: increment app.error.count\n    DogStatsD->>Agent: custom metric with tags\n\n    App->>Logs: write structured ERROR log with stack trace\n    Logs->>Agent: collect stdout\/stderr logs\n\n    App->>APM: mark span as error\n    APM->>Agent: send trace\/span data\n\n    Agent->>Agent: attach Kubernetes metadata\n    Agent->>DD: send metrics, logs, traces\n\n    DD->>ET: group similar errors into issues\n    ET->>DD: issue with service\/env\/version\/pod\/container context\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
8. Implement DogStatsD error metrics<\/h1>\n\n\n\n
DogStatsD should be used for counting and alerting<\/strong>, not for full stack traces.<\/p>\n\n\n\n
Recommended metric:<\/p>\n\n\n\n
app.error.count\n<\/code><\/pre>\n\n\n\n
Recommended tags:<\/p>\n\n\n\n
env\nservice\nversion\nerror_type\noperation\nendpoint\nhttp_status\nhandled\n<\/code><\/pre>\n\n\n\n
Avoid high-cardinality tags:<\/p>\n\n\n\n
request_id\nuser_id\nsession_id\norder_id\nfull_url\nfull_error_message\nstack_trace\npod_name unless intentionally needed\n<\/code><\/pre>\n\n\n\n
Bad metric design:<\/p>\n\n\n\n
app.error.count{user_id:12345,request_id:abc,error_message:payment failed for order 998877}\n<\/code><\/pre>\n\n\n\n
Good metric design:<\/p>\n\n\n\n
app.error.count{\n  env:prod,\n  service:checkout-api,\n  version:1.8.4,\n  error_type:PaymentTimeoutException,\n  operation:checkout,\n  endpoint:\/api\/checkout,\n  http_status:500,\n  handled:false\n}\n<\/code><\/pre>\n\n\n\n
8.1 Generic application pattern<\/h2>\n\n\n\n
try:\n    process_request()\nexcept Exception as err:\n    dogstatsd.increment(\n        \"app.error.count\",\n        tags=[\n            \"error_type:\" + err.class_name,\n            \"operation:checkout\",\n            \"endpoint:\/api\/checkout\",\n            \"http_status:500\",\n            \"handled:false\"\n        ]\n    )\n\n    logger.error(\n        \"Checkout failed\",\n        error=err,\n        stack_trace=true,\n        fields={\n            \"error.kind\": err.class_name,\n            \"error.message\": err.message,\n            \"error.stack\": err.stack,\n            \"operation\": \"checkout\",\n            \"endpoint\": \"\/api\/checkout\",\n            \"http.status_code\": 500\n        }\n    )\n\n    raise\n<\/code><\/pre>\n\n\n\n
8.2 Python example<\/h2>\n\n\n\n
import os\nimport traceback\nimport logging\nfrom datadog import DogStatsd\n\nlogger = logging.getLogger(__name__)\n\nstatsd = DogStatsd(\n    socket_path=os.getenv(\"DOGSTATSD_SOCKET\", \"\/var\/run\/datadog\/dsd.socket\")\n)\n\ndef checkout(request):\n    try:\n        # business logic here\n        process_payment(request)\n\n    except Exception as exc:\n        error_type = exc.__class__.__name__\n        stack = traceback.format_exc()\n\n        statsd.increment(\n            \"app.error.count\",\n            tags=[\n                f\"error_type:{error_type}\",\n                \"operation:checkout\",\n                \"endpoint:\/api\/checkout\",\n                \"http_status:500\",\n                \"handled:false\",\n            ],\n        )\n\n        logger.error(\n            \"Checkout failed\",\n            extra={\n                \"status\": \"error\",\n                \"error.kind\": error_type,\n                \"error.message\": str(exc),\n                \"error.stack\": stack,\n                \"operation\": \"checkout\",\n                \"endpoint\": \"\/api\/checkout\",\n                \"http.status_code\": 500,\n            },\n        )\n\n        raise\n<\/code><\/pre>\n\n\n\n
8.3 Node.js example<\/h2>\n\n\n\n
const StatsD = require(\"hot-shots\");\nconst logger = require(\".\/logger\");\n\nconst dogstatsd = new StatsD({\n  path: process.env.DOGSTATSD_SOCKET || \"\/var\/run\/datadog\/dsd.socket\"\n});\n\nasync function checkout(req, res) {\n  try {\n    await processPayment(req.body);\n    res.status(200).send({ status: \"ok\" });\n  } catch (err) {\n    dogstatsd.increment(\"app.error.count\", 1, [\n      `error_type:${err.name}`,\n      \"operation:checkout\",\n      \"endpoint:\/api\/checkout\",\n      \"http_status:500\",\n      \"handled:false\"\n    ]);\n\n    logger.error({\n      status: \"error\",\n      message: \"Checkout failed\",\n      \"error.kind\": err.name,\n      \"error.message\": err.message,\n      \"error.stack\": err.stack,\n      operation: \"checkout\",\n      endpoint: \"\/api\/checkout\",\n      \"http.status_code\": 500\n    });\n\n    throw err;\n  }\n}\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
9. Implement structured logs for Error Tracking<\/h1>\n\n\n\n
This is where you get the Sentry-like stack trace.<\/p>\n\n\n\n
For Datadog Error Tracking from backend logs, the log should include:<\/p>\n\n\n\n
status = ERROR \/ CRITICAL \/ ALERT \/ EMERGENCY\nservice\nerror.kind or error.stack\n<\/code><\/pre>\n\n\n\n
Datadog documents that backend error logs need either error.kind<\/code> or a valid error.stack<\/code>, a service attribute, and an error-level status. For better grouping, include error.message<\/code> and error.stack<\/code>. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
Recommended JSON log:<\/p>\n\n\n\n
{\n  \"timestamp\": \"2026-05-18T10:00:00.000Z\",\n  \"status\": \"error\",\n  \"service\": \"checkout-api\",\n  \"env\": \"prod\",\n  \"version\": \"1.8.4\",\n  \"message\": \"Checkout failed\",\n  \"error.kind\": \"PaymentTimeoutException\",\n  \"error.message\": \"Payment provider timed out\",\n  \"error.stack\": \"PaymentTimeoutException: Payment provider timed out\\n    at CheckoutService.pay...\",\n  \"operation\": \"checkout\",\n  \"endpoint\": \"\/api\/checkout\",\n  \"http.status_code\": 500\n}\n<\/code><\/pre>\n\n\n\n
Recommended log rule:<\/p>\n\n\n\n
Application logs should go to stdout\/stderr.\nDatadog Agent should collect container logs from the node.\nLogs should be JSON if possible.\nEach error log should contain service, env, version, error.kind, error.message, error.stack.\n<\/code><\/pre>\n\n\n\n
For Kubernetes, Datadog recommends Agent-based log collection and can collect logs from Kubernetes log files. File-based collection is preferred over Docker socket-based collection for performance and reliability in containerized environments. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
\n\n\n\n
10. Implement APM for request-level debugging<\/h1>\n\n\n\n
APM is what lets you answer:<\/p>\n\n\n\n
Which API failed?\nWhich downstream service failed?\nWas it database, cache, third-party API, timeout, or code exception?\nWhich trace\/log belongs to this error?\n<\/code><\/pre>\n\n\n\n
Flow:<\/p>\n\n\n\n
flowchart TD\n    REQ[Incoming Request \/api\/checkout] --> SPAN1[checkout-api span]\n    SPAN1 --> SPAN2[payment-service HTTP call]\n    SPAN1 --> SPAN3[database query]\n    SPAN2 --> ERR[Timeout Exception]\n    ERR --> TRACE[Trace marked as error]\n    TRACE --> ET[Error Tracking Issue]\n    TRACE --> LOG[Connected Logs]\n    TRACE --> POD[Pod and Container Metadata]\n<\/code><\/pre>\n\n\n\n
Recommended APM environment variables:<\/p>\n\n\n\n
env:\n  - name: DD_ENV\n    value: \"prod\"\n\n  - name: DD_SERVICE\n    value: \"checkout-api\"\n\n  - name: DD_VERSION\n    value: \"1.8.4\"\n\n  - name: DD_TRACE_AGENT_URL\n    value: \"unix:\/\/\/var\/run\/datadog\/apm.socket\"\n\n  - name: DD_LOGS_INJECTION\n    value: \"true\"\n\n  - name: DD_RUNTIME_METRICS_ENABLED\n    value: \"true\"\n<\/code><\/pre>\n\n\n\n
Datadog APM on Kubernetes supports UDS, host IP, or Kubernetes service routing for traces. In containerized environments, sending traces to localhost<\/code> is usually wrong because the Agent is in another container\/pod; for Kubernetes, use UDS, node host IP, Admission Controller injection, or a Kubernetes service pattern. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
\n\n\n\n
11. How Error Tracking groups errors<\/h1>\n\n\n\n
Datadog Error Tracking groups similar errors into issues based on properties such as:<\/p>\n\n\n\n
service\nerror.type \/ error.kind\nerror.message\nerror.stack\ntop meaningful stack frame\n<\/code><\/pre>\n\n\n\n
So two errors may become separate issues if they happen in different services or have different error types\/stack-frame locations. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
checkout-api + PaymentTimeoutException + CheckoutService.pay()\n= One Error Tracking issue\n<\/code><\/pre>\n\n\n\n
payment-service + PaymentTimeoutException + PaymentClient.call()\n= Different Error Tracking issue\n<\/code><\/pre>\n\n\n\n
This is why service<\/code>, error.kind<\/code>, and error.stack<\/code> matter so much.<\/p>\n\n\n\n
\n\n\n\n
12. Recommended tag strategy<\/h1>\n\n\n\n
Mandatory tags<\/h2>\n\n\n\n
Tag<\/th>Example<\/th>Purpose<\/th><\/tr><\/thead>
env<\/code><\/td>prod<\/code><\/td>Separate prod\/stage\/dev<\/td><\/tr>
service<\/code><\/td>checkout-api<\/code><\/td>Service-level ownership<\/td><\/tr>
version<\/code><\/td>1.8.4<\/code><\/td>Release\/deployment tracking<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Strongly recommended tags<\/h2>\n\n\n\n
Tag<\/th>Example<\/th>Purpose<\/th><\/tr><\/thead>
team<\/code><\/td>payments<\/code><\/td>Ownership<\/td><\/tr>
product<\/code><\/td>motoshare<\/code><\/td>Product\/application grouping<\/td><\/tr>
component<\/code><\/td>api<\/code><\/td>API\/worker\/consumer grouping<\/td><\/tr>
operation<\/code><\/td>checkout<\/code><\/td>Business flow<\/td><\/tr>
endpoint<\/code><\/td>\/api\/checkout<\/code><\/td>API route<\/td><\/tr>
error_type<\/code><\/td>PaymentTimeoutException<\/code><\/td>Error classification<\/td><\/tr>
handled<\/code><\/td>true\/false<\/code><\/td>Handled vs unhandled error<\/td><\/tr>
cloud<\/code><\/td>aws<\/code><\/td>Cloud provider<\/td><\/tr>
platform<\/code><\/td>eks<\/code><\/td>Runtime platform<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Kubernetes tags Datadog can add<\/h2>\n\n\n\n
kube_cluster_name\nkube_namespace\nkube_deployment\nkube_replica_set\npod_name\ncontainer_name\nimage_name\nimage_tag\nnode\navailability_zone\n<\/code><\/pre>\n\n\n\n
For DogStatsD metrics, be careful with tag cardinality. Datadog notes that for UDP DogStatsD, pod_name<\/code> is not added by default to avoid creating too many custom metrics, and tag cardinality can be controlled globally or per metric. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
My recommendation:<\/p>\n\n\n\n
Use service\/version-level DogStatsD metrics for alerting.\nUse logs\/APM\/Error Tracking for exact pod\/container investigation.\nUse pod-level metric tagging only when you really need it.\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
13. Complete application telemetry flow<\/h1>\n\n\n\n
flowchart TD\n    A[Exception in Application] --> B{Telemetry Type}\n\n    B --> C[DogStatsD Counter]\n    C --> C1[app.error.count]\n    C1 --> C2[Alert: Error spike by service\/version]\n\n    B --> D[Structured Error Log]\n    D --> D1[error.kind]\n    D --> D2[error.message]\n    D --> D3[error.stack]\n    D3 --> D4[Error Tracking Issue]\n\n    B --> E[APM Trace]\n    E --> E1[Trace marked error]\n    E1 --> E2[Request path]\n    E2 --> E3[Downstream dependency failure]\n\n    B --> F[Kubernetes Metadata]\n    F --> F1[pod_name]\n    F --> F2[container_name]\n    F --> F3[kube_deployment]\n    F --> F4[node]\n\n    C2 --> G[Datadog Incident \/ Monitor]\n    D4 --> G\n    E3 --> G\n    F4 --> G\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
14. Build dashboards<\/h1>\n\n\n\n
14.1 Error count by service<\/h2>\n\n\n\n
sum:app.error.count{env:prod} by {service}.as_count()\n<\/code><\/pre>\n\n\n\n
14.2 Error count by version<\/h2>\n\n\n\n
sum:app.error.count{env:prod,service:checkout-api} by {version}.as_count()\n<\/code><\/pre>\n\n\n\n
Use this to answer:<\/p>\n\n\n\n
Did the new release increase errors?\n<\/code><\/pre>\n\n\n\n
14.3 Error count by operation<\/h2>\n\n\n\n
sum:app.error.count{env:prod,service:checkout-api} by {operation}.as_count()\n<\/code><\/pre>\n\n\n\n
Use this to answer:<\/p>\n\n\n\n
Which business flow is failing?\n<\/code><\/pre>\n\n\n\n
14.4 Error count by error type<\/h2>\n\n\n\n
sum:app.error.count{env:prod,service:checkout-api} by {error_type}.as_count()\n<\/code><\/pre>\n\n\n\n
Use this to answer:<\/p>\n\n\n\n
Which exception is most common?\n<\/code><\/pre>\n\n\n\n
14.5 Error count by Kubernetes deployment<\/h2>\n\n\n\n
sum:app.error.count{env:prod} by {kube_namespace,kube_deployment}.as_count()\n<\/code><\/pre>\n\n\n\n
Use this to answer:<\/p>\n\n\n\n
Which deployment is producing the errors?\n<\/code><\/pre>\n\n\n\n
14.6 Pod-level view<\/h2>\n\n\n\n
Only use this if your DogStatsD metric cardinality\/tagging supports it:<\/p>\n\n\n\n
sum:app.error.count{env:prod,service:checkout-api} by {pod_name}.as_count()\n<\/code><\/pre>\n\n\n\n
For exact pod-level investigation, I would rely more on logs\/APM\/Error Tracking because pod-level metrics can create high cardinality and cost\/noise.<\/p>\n\n\n\n
\n\n\n\n
15. Build monitors and alerts<\/h1>\n\n\n\n
15.1 Metric monitor: service error spike<\/h2>\n\n\n\n
sum(last_5m):sum:app.error.count{env:prod,service:checkout-api}.as_count() > 50\n<\/code><\/pre>\n\n\n\n
Alert message:<\/p>\n\n\n\n
High application error count detected.\n\nService: {{service.name}}\nEnvironment: {{env.name}}\nVersion: {{version.name}}\n\nCheck:\n- Error Tracking issue\n- APM trace\n- Logs for error.stack\n- Kubernetes pod\/container details\n<\/code><\/pre>\n\n\n\n
15.2 Metric monitor: new version error spike<\/h2>\n\n\n\n
sum(last_10m):sum:app.error.count{env:prod,service:checkout-api} by {version}.as_count() > 100\n<\/code><\/pre>\n\n\n\n
Use this after deployments.<\/p>\n\n\n\n
15.3 Error Tracking monitor: new issue<\/h2>\n\n\n\n
Use this for Sentry-like behavior:<\/p>\n\n\n\n
Alert when a new backend issue appears for service:checkout-api env:prod\n<\/code><\/pre>\n\n\n\n
Datadog Error Tracking monitors support alerting on new issues, regressions, and high-impact errors. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
15.4 APM monitor: error rate<\/h2>\n\n\n\n
Example logic:<\/p>\n\n\n\n
Error rate for checkout-api > 5% during last 5 minutes\n<\/code><\/pre>\n\n\n\n
Use this for service reliability monitoring.<\/p>\n\n\n\n
\n\n\n\n
16. Recommended alerting strategy<\/h1>\n\n\n\n
Do not create only one giant alert.<\/p>\n\n\n\n
Use layered alerting:<\/p>\n\n\n\n
flowchart TD\n    A[Application Errors] --> B[Metric Alert]\n    A --> C[Error Tracking New Issue Alert]\n    A --> D[APM Error Rate Alert]\n    A --> E[Kubernetes Pod Restart Alert]\n\n    B --> F[High volume problem]\n    C --> G[New code issue]\n    D --> H[Request failure problem]\n    E --> I[Runtime\/container problem]\n\n    F --> J[Incident]\n    G --> J\n    H --> J\n    I --> J\n<\/code><\/pre>\n\n\n\n
Alert type<\/th>Detects<\/th>Best for<\/th><\/tr><\/thead>
DogStatsD metric alert<\/td>Error volume spike<\/td>Fast service-level alert<\/td><\/tr>
Error Tracking alert<\/td>New\/regressed grouped error<\/td>Sentry-like issue detection<\/td><\/tr>
APM error rate alert<\/td>Request failure percentage<\/td>API\/SLO reliability<\/td><\/tr>
Log alert<\/td>Specific log pattern<\/td>Known failure modes<\/td><\/tr>
Kubernetes alert<\/td>CrashLoopBackOff\/restarts<\/td>Pod\/container health<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
17. Best practice: use DogStatsD for counters, not stack traces<\/h1>\n\n\n\n
DogStatsD should answer:<\/p>\n\n\n\n
How many errors happened?\nWhich service\/version\/operation is failing?\nDid errors increase after deployment?\n<\/code><\/pre>\n\n\n\n
DogStatsD should not answer:<\/p>\n\n\n\n
What is the stack trace?\nWhich line of code failed?\nWhat was the exception body?\nWhat user\/request caused this?\n<\/code><\/pre>\n\n\n\n
Those belong in:<\/p>\n\n\n\n
APM\nLogs\nError Tracking\nTrace\/log correlation\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
18. Best practice: standardize error classification<\/h1>\n\n\n\n
Create a small taxonomy across all services.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
validation_error\ndependency_timeout\ndatabase_error\nauthentication_error\nauthorization_error\nbusiness_rule_error\nunexpected_exception\n<\/code><\/pre>\n\n\n\n
Then tag DogStatsD metrics like this:<\/p>\n\n\n\n
error_category:dependency_timeout\nerror_type:PaymentTimeoutException\noperation:checkout\n<\/code><\/pre>\n\n\n\n
This gives clean dashboards:<\/p>\n\n\n\n
Errors by category\nErrors by operation\nErrors by service\nErrors by version\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
19. Best practice: release\/version tracking<\/h1>\n\n\n\n
Every deployment should set a unique version<\/code>.<\/p>\n\n\n\n
Good:<\/p>\n\n\n\n
version: 1.8.4\nversion: git-sha-a8f91cd\nversion: 2026.05.18.1\n<\/code><\/pre>\n\n\n\n
Bad:<\/p>\n\n\n\n
version: latest\nversion: prod\nversion: main\n<\/code><\/pre>\n\n\n\n
Datadog expects version<\/code> to change with each application deployment so deployment impact can be identified cleanly. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
\n\n\n\n
20. Best practice: log format<\/h1>\n\n\n\n
Use JSON logs.<\/p>\n\n\n\n
Recommended fields:<\/p>\n\n\n\n
{\n  \"status\": \"error\",\n  \"service\": \"checkout-api\",\n  \"env\": \"prod\",\n  \"version\": \"1.8.4\",\n  \"message\": \"Checkout failed\",\n  \"error.kind\": \"PaymentTimeoutException\",\n  \"error.message\": \"Payment provider timed out\",\n  \"error.stack\": \"...\",\n  \"operation\": \"checkout\",\n  \"endpoint\": \"\/api\/checkout\",\n  \"http.method\": \"POST\",\n  \"http.status_code\": 500,\n  \"customer_impact\": true\n}\n<\/code><\/pre>\n\n\n\n
Avoid logging sensitive data:<\/p>\n\n\n\n
password\ntoken\ncredit card\npersonal identity data\nfull request payloads\nauthorization headers\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
21. Best practice: deployment annotation for logs<\/h1>\n\n\n\n
For each application container, add Datadog log annotation:<\/p>\n\n\n\n
annotations:\n  ad.datadoghq.com\/checkout-api.logs: >\n    [{\n      \"source\": \"java\",\n      \"service\": \"checkout-api\",\n      \"tags\": [\"team:payments\",\"component:api\"]\n    }]\n<\/code><\/pre>\n\n\n\n
Use the right source<\/code> value:<\/p>\n\n\n\n
App language\/runtime<\/th>source<\/code><\/th><\/tr><\/thead>
Java<\/td>java<\/code><\/td><\/tr>
Node.js<\/td>nodejs<\/code><\/td><\/tr>
Python<\/td>python<\/code><\/td><\/tr>
Go<\/td>go<\/code><\/td><\/tr>
.NET<\/td>csharp<\/code> or configured .NET source<\/td><\/tr>
Ruby<\/td>ruby<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The source<\/code> tag matters because Datadog\u2019s Error Tracking for logs uses language-specific handling, and Datadog recommends ensuring the source tag is properly configured. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
\n\n\n\n
22. Pod\/container relationship design<\/h1>\n\n\n\n
The relationship is built from three places:<\/p>\n\n\n\n
flowchart TD\n    A[Application Deployment Labels] --> D[env\/service\/version]\n    B[Datadog Agent Kubernetes Metadata] --> E[pod\/container\/deployment\/node]\n    C[Application Logs\/APM\/DogStatsD] --> F[error\/trace\/metric]\n\n    D --> G[Unified Datadog View]\n    E --> G\n    F --> G\n\n    G --> H[Which service failed?]\n    G --> I[Which version failed?]\n    G --> J[Which pod\/container failed?]\n    G --> K[Which node hosted it?]\n<\/code><\/pre>\n\n\n\n
To make this work:<\/p>\n\n\n\n
1. Datadog Agent must run in the cluster.\n2. App pods must have unified service tags.\n3. Logs\/APM\/DogStatsD must use the same service\/env\/version.\n4. Error logs must include error.kind\/error.stack.\n5. APM tracer should inject trace\/log correlation where supported.\n6. DogStatsD origin detection should be enabled.\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
23. EKS-specific implementation notes<\/h1>\n\n\n\n
Standard EKS with EC2 worker nodes<\/h2>\n\n\n\n
Recommended:<\/p>\n\n\n\n
Datadog Agent as DaemonSet\nUse UDS for APM\nUse UDS for DogStatsD\nCollect container logs from nodes\nUse Cluster Agent\nUse Admission Controller where possible\n<\/code><\/pre>\n\n\n\n
EKS Fargate<\/h2>\n\n\n\n
Be careful. EKS Fargate does not behave like normal EC2 worker nodes because you do not manage the underlying node the same way. Datadog\u2019s DogStatsD origin detection docs specifically mention shareProcessNamespace:true<\/code> to assist the Agent for origin detection on EKS Fargate. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
If you are using Fargate, validate the Datadog deployment pattern separately.<\/p>\n\n\n\n
\n\n\n\n
24. End-to-end sample implementation<\/h1>\n\n\n\n
24.1 Datadog Agent values<\/h2>\n\n\n\n
targetSystem: linux\n\ndatadog:\n  apiKeyExistingSecret: datadog-secret\n  site: datadoghq.com\n  clusterName: eks-prod-apne1-01\n\n  logs:\n    enabled: true\n    containerCollectAll: true\n\n  apm:\n    socketEnabled: true\n    portEnabled: false\n\n  dogstatsd:\n    originDetection: true\n    useSocketVolume: true\n    socketPath: \/var\/run\/datadog\/dsd.socket\n    tagCardinality: orchestrator\n\n  kubeStateMetricsCore:\n    enabled: true\n\n  collectEvents: true\n\nclusterAgent:\n  enabled: true\n  admissionController:\n    enabled: true\n    mutateUnlabelled: false\n<\/code><\/pre>\n\n\n\n
24.2 App deployment<\/h2>\n\n\n\n
apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: checkout-api\n  namespace: prod\n  labels:\n    tags.datadoghq.com\/env: \"prod\"\n    tags.datadoghq.com\/service: \"checkout-api\"\n    tags.datadoghq.com\/version: \"1.8.4\"\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: checkout-api\n  template:\n    metadata:\n      labels:\n        app: checkout-api\n        tags.datadoghq.com\/env: \"prod\"\n        tags.datadoghq.com\/service: \"checkout-api\"\n        tags.datadoghq.com\/version: \"1.8.4\"\n      annotations:\n        admission.datadoghq.com\/enabled: \"true\"\n        ad.datadoghq.com\/checkout-api.logs: >\n          [{\n            \"source\": \"java\",\n            \"service\": \"checkout-api\",\n            \"tags\": [\"team:payments\",\"component:api\"]\n          }]\n    spec:\n      containers:\n        - name: checkout-api\n          image: myrepo\/checkout-api:1.8.4\n          env:\n            - name: DD_ENV\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.labels['tags.datadoghq.com\/env']\n\n            - name: DD_SERVICE\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.labels['tags.datadoghq.com\/service']\n\n            - name: DD_VERSION\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.labels['tags.datadoghq.com\/version']\n\n            - name: DD_ENTITY_ID\n              valueFrom:\n                fieldRef:\n                  fieldPath: metadata.uid\n\n            - name: DD_TRACE_AGENT_URL\n              value: \"unix:\/\/\/var\/run\/datadog\/apm.socket\"\n\n            - name: DD_LOGS_INJECTION\n              value: \"true\"\n\n            - name: DD_RUNTIME_METRICS_ENABLED\n              value: \"true\"\n\n            - name: DOGSTATSD_SOCKET\n              value: \"\/var\/run\/datadog\/dsd.socket\"\n\n          volumeMounts:\n            - name: datadog-socket\n              mountPath: \/var\/run\/datadog\n              readOnly: true\n\n      volumes:\n        - name: datadog-socket\n          hostPath:\n            path: \/var\/run\/datadog\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
25. Validation checklist<\/h1>\n\n\n\n
25.1 Validate Datadog Agent<\/h2>\n\n\n\n
kubectl -n datadog get pods\nkubectl -n datadog get ds\nkubectl -n datadog get deploy\n<\/code><\/pre>\n\n\n\n
25.2 Check Agent status<\/h2>\n\n\n\n
kubectl -n datadog exec -it <datadog-agent-pod-name> -c agent -- agent status\n<\/code><\/pre>\n\n\n\n
Look for:<\/p>\n\n\n\n
APM Agent: Running\nDogStatsD: Running\nLogs Agent: Running\n<\/code><\/pre>\n\n\n\n
Datadog\u2019s APM troubleshooting guide says the Agent status output should show the APM Agent as running; otherwise traces cannot be submitted properly. (Datadog Monitoring<\/a>)<\/p>\n\n\n\n
25.3 Validate app tags<\/h2>\n\n\n\n
Check pod labels:<\/p>\n\n\n\n
kubectl -n prod get pod <pod-name> --show-labels\n<\/code><\/pre>\n\n\n\n
Expected:<\/p>\n\n\n\n
tags.datadoghq.com\/env=prod\ntags.datadoghq.com\/service=checkout-api\ntags.datadoghq.com\/version=1.8.4\n<\/code><\/pre>\n\n\n\n
25.4 Validate logs<\/h2>\n\n\n\n
Generate a test exception, then search logs by:<\/p>\n\n\n\n
service:checkout-api env:prod status:error\n<\/code><\/pre>\n\n\n\n
Expected fields:<\/p>\n\n\n\n
error.kind\nerror.message\nerror.stack\nkube_namespace\npod_name\ncontainer_name\n<\/code><\/pre>\n\n\n\n
25.5 Validate DogStatsD metric<\/h2>\n\n\n\n
Search metric:<\/p>\n\n\n\n
app.error.count\n<\/code><\/pre>\n\n\n\n
Group by:<\/p>\n\n\n\n
service\nversion\nerror_type\noperation\n<\/code><\/pre>\n\n\n\n
25.6 Validate APM<\/h2>\n\n\n\n
Search service:<\/p>\n\n\n\n
service:checkout-api env:prod\n<\/code><\/pre>\n\n\n\n
Expected:<\/p>\n\n\n\n
Traces visible\nError traces visible\nService map visible\nTrace\/log correlation working\n<\/code><\/pre>\n\n\n\n
25.7 Validate Error Tracking<\/h2>\n\n\n\n
Search backend issues for:<\/p>\n\n\n\n
service:checkout-api env:prod\n<\/code><\/pre>\n\n\n\n
Expected:<\/p>\n\n\n\n
Grouped error issue\nStack trace visible\nOccurrences visible\nRelated logs\/traces visible\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
26. Common problems and fixes<\/h1>\n\n\n\n
Problem<\/th>Likely cause<\/th>Fix<\/th><\/tr><\/thead>
Error metric appears but no pod\/container<\/td>DogStatsD origin detection\/cardinality issue<\/td>Enable origin detection; use UDS; review tag cardinality<\/td><\/tr>
Error Tracking issue not created<\/td>Logs missing error.kind<\/code> or error.stack<\/code><\/td>Add structured error fields<\/td><\/tr>
Logs visible but service name wrong<\/td>Missing log annotation or unified tags<\/td>Add service<\/code> in log config and DD_SERVICE<\/code><\/td><\/tr>
APM traces missing<\/td>App cannot reach Agent<\/td>Use UDS or correct DD_AGENT_HOST<\/code>; check Agent status<\/td><\/tr>
Trace\/log correlation missing<\/td>Log injection not enabled<\/td>Enable tracer log injection<\/td><\/tr>
Too many custom metrics<\/td>High-cardinality metric tags<\/td>Remove request_id<\/code>, user_id<\/code>, pod_name<\/code> from metrics<\/td><\/tr>
New release not visible<\/td>Static or missing version<\/code><\/td>Set unique DD_VERSION<\/code> per deployment<\/td><\/tr>
Pod error not visible in metric<\/td>Pod tag not included for cardinality reasons<\/td>Use logs\/APM for pod-level RCA or adjust cardinality carefully<\/td><\/tr>
Logs not collected<\/td>Agent log collection disabled<\/td>Enable container log collection<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
27. Best implementation pattern for your migration<\/h1>\n\n\n\n
Do not migrate like this:<\/p>\n\n\n\n
Sentry \u2192 DogStatsD only\n<\/code><\/pre>\n\n\n\n
That will give weak debugging.<\/p>\n\n\n\n
Migrate like this:<\/p>\n\n\n\n
Sentry\n  \u2192 Datadog Error Tracking\n  \u2192 Datadog APM\n  \u2192 Datadog Logs\n  \u2192 DogStatsD custom error metrics\n  \u2192 Kubernetes metadata correlation\n<\/code><\/pre>\n\n\n\n
Recommended production pattern:<\/p>\n\n\n\n
flowchart TD\n    A[Sentry Replacement Requirement] --> B[Error Tracking]\n    A --> C[APM]\n    A --> D[Logs]\n    A --> E[DogStatsD Metrics]\n\n    B --> F[Grouped Issues]\n    C --> G[Trace and Dependency RCA]\n    D --> H[Stack Trace and Context]\n    E --> I[Fast Error Count Alerts]\n\n    F --> J[Service \/ Env \/ Version]\n    G --> J\n    H --> J\n    I --> J\n\n    J --> K[Kubernetes Pod \/ Container \/ Deployment \/ Node]\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
28. Final recommended standard<\/h1>\n\n\n\n
For every service running in EKS, implement this standard:<\/p>\n\n\n\n
1. Add Datadog unified service labels:\n   - tags.datadoghq.com\/env\n   - tags.datadoghq.com\/service\n   - tags.datadoghq.com\/version\n\n2. Add application env vars:\n   - DD_ENV\n   - DD_SERVICE\n   - DD_VERSION\n   - DD_TRACE_AGENT_URL\n   - DD_LOGS_INJECTION\n   - DD_ENTITY_ID\n\n3. Enable Datadog Agent features:\n   - logs\n   - APM\n   - DogStatsD\n   - DogStatsD origin detection\n   - Kubernetes metadata\n   - Cluster Agent\n\n4. Application must emit:\n   - DogStatsD metric: app.error.count\n   - Structured error log with error.kind\/error.message\/error.stack\n   - APM trace\/span errors\n\n5. Dashboards should show:\n   - errors by service\n   - errors by version\n   - errors by operation\n   - errors by error_type\n   - errors by namespace\/deployment\n   - related pods\/containers through logs\/APM\n\n6. Alerts should include:\n   - new Error Tracking issue\n   - high error count\n   - high APM error rate\n   - pod restart\/crashloop alerts\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
29. Final conclusion<\/h1>\n\n\n\n
The best Datadog design for application error tracking in EKS is:<\/p>\n\n\n\n
DogStatsD for custom error counters\nLogs for stack traces\nAPM for request\/dependency tracing\nError Tracking for Sentry-like issue grouping\nUnified service tagging for service\/env\/version relationship\nKubernetes metadata for pod\/container\/node relationship\n<\/code><\/pre>\n\n\n\n
In short:<\/p>\n\n\n\n
DogStatsD tells you how many errors happened.\nLogs tell you what exception happened.\nAPM tells you where in the request path it failed.\nError Tracking groups the issue.\nKubernetes metadata tells you which pod\/container\/deployment\/node caused it.\n<\/code><\/pre>\n\n\n\n
That combination gives you a clean, production-grade replacement for Sentry while also giving stronger EKS infrastructure correlation than Sentry alone.<\/p>\n","protected":false},"excerpt":{"rendered":"
Master Guide: Application Error Tracking in EKS using Datadog, DogStatsD, APM, Logs, and Error Tracking First, tiny naming correction: it is DogStatsD, not DogStashD. DogStatsD is Datadog\u2019s… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-993","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/993","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=993"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/993\/revisions"}],"predecessor-version":[{"id":994,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/993\/revisions\/994"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=993"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=993"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=993"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}