Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

bug: datadog plugin drops service_name tag when service has no name configured

Open Beginner friendly
  • Is something wrong?
#14,000 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
85/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
lua
Domain
backend, observability

Research direction

Start in apisix/plugins/datadog.lua at the prefer_name service-name resolution shown in the issue. Check how a service with no configured name is handled, then run or add a focused test for the Datadog plugin with prefer_name enabled and a nameless service. Done when the emitted metric tags retain service_name:s1 rather than omitting the tag.

Written by the indexing model from the issue text.

Description

Current Behavior

In apisix/plugins/datadog.lua, when prefer_name is enabled (default is true), the plugin attempts to resolve the service name:

-- if prefer_name is set, fetch the service/route name. If the name is nil, fall back to id.
if conf.prefer_name then
    if entry.service_id and entry.service_id ~= "" then
        local svc = service_fetch(entry.service_id)

        if svc and svc.value.name ~= "" then
            entry.service_id =  svc.value.name
        end
    end
    ...

In Lua, nil ~= "" evaluates to true. When a service exists in APISIX but has no name property set (the name field in Service schema is optional), svc.value.name is nil.

Because nil ~= "" is true, the condition if svc and svc.value.name ~= "" evaluates to true, and entry.service_id is assigned svc.value.name (nil), overwriting the valid service ID.

Consequently, when generate_tag() builds the metric tags:

local variable_tags = {
    ...
    {"service_name", entry.service_id},
    ...
}

entry.service_id is nil, so the service_name tag is completely omitted from the emitted DogStatsD metric datagrams instead of falling back to the service ID as intended.

Expected Behavior

When a Service does not have a name configured (svc.value.name == nil), entry.service_id should remain set to the service's ID, and service_name:<id> should be emitted in Datadog metrics tags.

Error Logs

No error logs are printed because Lua executes the assignment silently. However, inspecting the emitted UDP DogStatsD datagrams reveals that service_name is missing from the tags list whenever the associated service lacks an explicit name.

Steps to Reproduce
  1. Create an upstream and a service without specifying a name: 
    curl -i http://127.0.0.1:9180/apisix/admin/services/s1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "upstream": {
        "type": "roundrobin",
        "nodes": {"127.0.0.1:1980": 1}
    }
}'
  2. Create a route referencing service s1 with datadog plugin enabled (prefer_name: true by default): 
    curl -i http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/hello",
    "service_id": "s1",
    "plugins": {
        "datadog": {}
    }
}'
  3. Send a request to /hello.
  4. Observe the DogStatsD UDP packets received at port 8125: the tags contain route_name:1, path:..., but service_name:s1 is completely absent because entry.service_id was overwritten with nil.
Environment
  • APISIX version (run apisix version): 3.19.0 (master @ c6b2adc3)
  • Operating system (run uname -a): Linux / POSIX
  • OpenResty / Nginx version (run openresty -V or nginx -V): OpenResty 1.25+
  • etcd version, if relevant: N/A
  • APISIX Dashboard version, if relevant: N/A
  • Plugin runner version, for issues related to plugin runners: N/A
  • LuaRocks version, for installation issues: N/A
Dominant language
Lua
Stars
17.2k
Forks
3k
Avg merge
2d 19h
Merged PRs (30d)
37

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/apisix

All issues in apache/apisix

Similar issues

More Lua issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.