-
Notifications
You must be signed in to change notification settings - Fork 525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a configurable default service environment #4861
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪 |
7f8c1c6
to
7cb3eab
Compare
Codecov Report
@@ Coverage Diff @@
## master #4861 +/- ##
==========================================
- Coverage 76.77% 76.71% -0.06%
==========================================
Files 166 167 +1
Lines 10230 10265 +35
==========================================
+ Hits 7854 7875 +21
- Misses 2376 2390 +14
|
7cb3eab
to
8a37add
Compare
8a37add
to
5d10a73
Compare
case *model.Error: | ||
if t.Metadata.Service.Environment == "" { | ||
t.Metadata.Service.Environment = s.DefaultServiceEnvironment | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be exhaustive here? i prefer prefer that something fails loudly if eg. we add a new event type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point - it should be and it's not. I forgot to cover profiles.
I could make this panic if it sees a type it doesn't know about, but I'd rather not have this feature cause such a catastrophic failure in case test coverage isn't quite adequate (which evidently it's not).
I think ideally we wouldn't be dealing with a "Transformable" interface here at all, but instead pass around the concrete model.Batch
struct type. Then the processor can just iterate over the bits it cares about. We could have tests for processors that check the Batch type hasn't changed, if necessary.
I'd like to defer that, and just add Profile in for now. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good, thanks (create an issue, maybe?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #4877
@@ -62,6 +62,12 @@ policy_templates: | |||
required: false | |||
description: Enter as <Id>:<API Key> | |||
show_user: true | |||
- name: default_service_environment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure about this, shouldn't we use the namespace
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to keep them separate for now, so users have the flexibility to have two dimensions:
- a namespace is a collection of APM services, e.g. split by business applications, business unit, etc.
- typical environments for those services: production, testing, development
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok, that was news to me 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also update the README accordingly, it refers to using namespace
for environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be clear, setting namespace to environment is still a reasonable choice. Perhaps we should just soften the language a little, to point it out as an option but not necessarily state that it is recommended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that's what I meant, the additional use case for namespace
tha you explained above, should be added to the README.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -62,6 +62,12 @@ policy_templates: | |||
required: false | |||
description: Enter as <Id>:<API Key> | |||
show_user: true | |||
- name: default_service_environment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also update the README accordingly, it refers to using namespace
for environment.
Apologies - I just approved, but didn't see your ongoing conversation. |
One more question, sorry for delay: this intended for 7.13, I suppose? |
@jalvz yes, now labelled accordingly |
I was going to say that in that case better hold onto merging to allow for package changes for 7.12 😬 |
@jalvz I suppose if that's needed we should be working off the 7.12 branch instead. We'll eventually version the package with the stack right? So bump the version on master/7.x to 0.2.0 and have 0.1.0 on 7.12? |
* Add transform.Processor interface * beater: add default service environment * model/modelprocessor: update PprofProfile too * apmpackage: update README about namespace # Conflicts: # apmpackage/apm/0.1.0/_dev/docs/README.template.md # apmpackage/apm/0.1.0/docs/README.md # apmpackage/apm/0.1.0/manifest.yml # changelogs/head.asciidoc
* Add transform.Processor interface * beater: add default service environment * model/modelprocessor: update PprofProfile too * apmpackage: update README about namespace # Conflicts: # apmpackage/apm/0.1.0/_dev/docs/README.template.md # apmpackage/apm/0.1.0/docs/README.md # apmpackage/apm/0.1.0/manifest.yml # changelogs/head.asciidoc
* Add transform.Processor interface * beater: add default service environment * model/modelprocessor: update PprofProfile too * apmpackage: update README about namespace (cherry picked from commit 992699d) # Conflicts: # apmpackage/apm/0.1.0/manifest.yml # apmpackage/apm/0.2.0/README.template.md # apmpackage/apm/0.2.0/docs/README.md # beater/api/config/agent/handler_test.go # beater/beater.go # beater/config/config.go # changelogs/head.asciidoc # model/modelprocessor/environment.go # model/modelprocessor/environment_test.go # transform/transform.go # x-pack/apm-server/main.go
@axw Are there any plans to enable the default service environment by default? In APM UI we are planning to remove the "all" option as well as the "no environment" option. If we do that and users have data without environment it won't show up anymore. |
@sqren no plans at the moment. I recall we discussed this (taking away "all" and "none") in the past, and decided that it wasn't doable at the time. I think maybe because of backwards compatibility? What are we going to do for existing data? |
Yes, removing them now can be seen as a breaking change. Which is why I'd like to add a default environment asap so we can do it in ~18 months time (or whatever our data guarantees for APM data is). We could add a migration script that updates documents to ensure they have an environment. But it requires a re-index of all data so I'm not sure how feasible it is. |
@sqren can you create an issue for this so we can continue the discussion, including what the default env should be set to? I am not certain setting a default on the server would be more meaningful than having a |
Should I re-open https://github.com/elastic/observability-dev/issues/1118 since it already contains all the background? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4861 +/- ##
==========================================
- Coverage 76.58% 76.53% -0.06%
==========================================
Files 166 167 +1
Lines 10118 10156 +38
==========================================
+ Hits 7749 7773 +24
- Misses 2369 2383 +14
|
Motivation/summary
Introduce a configurable default service environment. This is recorded in events which have no service environment defined, and is used in agent central config when no environment is specified. There is no default default, so there is no change in behaviour unless the configuration is set.
Checklist
How to test these changes
apm-server.default_service_environment: abc123
Related issues
Closes #4664.