-
Notifications
You must be signed in to change notification settings - Fork 1.1k
feat: add flag to disable template insights #20940
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
base: main
Are you sure you want to change the base?
Conversation
46fd3d8 to
f5abd4e
Compare
📚 Documentation Check✅ Updates NeededNone - API documentation already updated in this PR 📝 New Docs Needed
📋 Already DocumentedThe PR appropriately updated:
📖 RecommendationWhile the reference documentation is complete, consider adding a user-facing guide that explains:
This would fit well in the This comment was generated by an AI Agent through Coder Tasks |
|
Ha - that's a lot. Feel free to disregard |
Proactively documents the --disable-template-insights flag from PR #20940 before it merges, ensuring documentation is ready when the feature lands.
This effectively disables template insights, as there will be no data. Prometheus remains unaffected; this only prevents our own storage of the stats.
It takes a timezone offset, not a date.
Now errors show up in the middle of the panel. This will include if the insights are disabled.
f5abd4e to
092cca4
Compare
mafredri
left a comment
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.
All-in-all looks good, but I have one concern regarding agent stats (see comments). The rest are smaller suggestions/nits.
Whilst I think the FE changes look good, I'll defer approval to someone from the FE team as I believe they may want emotion to be converted to tailwind whilst you're in here.
| SessionCountSsh: stat.sessionCountSSH, | ||
| }, false) | ||
| createdAt = createdAt.Add(30 * time.Second) | ||
| } |
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.
Consider if this needs a rethink in context of the previous comment about disabling agent stats batching.
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 might not quite be following, normally the reporter skips adding stats to the batcher but in the test here we are manually adding batches instead of delegating to the reporter, so I had to skip those separately here when we test disabled stats (otherwise we would have stats even though they are disabled).
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, this change makes sense. My "consider" was tied to the other concern about not storing agent stats, and depending on the direction taken there (two options, 1, restore agent stats are always stored, or 2, keep but document the behavior).
This callout was for option 1.
site/src/pages/TemplatePage/TemplateInsightsPage/TemplateInsightsPage.stories.tsx
Show resolved
Hide resolved
| Group: &deploymentGroupIntrospection, | ||
| YAML: "disableTemplateInsights", | ||
| Name: "Enable Template Insights", | ||
| Description: "Enable the collection and display of template insights along with the associated API endpoints. This will also enable aggregating these insights into daily active users, application usage, and transmission rates for overall deployment stats. When disabled, these values will be zero, which will also affect what the bottom deployment overview bar displays. Disabling will also prevent Prometheus collection of these values.", |
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 think this is everything affected by disabling collection of these stats. I am not sure I worded it clearly though, I went through so many revisions 😅
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.
It's on the verbose side, but I think it captures everything. Nice work. Just to be annoying though, I will propose the idea of separating template insights and agent stats, i.e. having two options. I think that would be clearer since the naming is lossy. The name "enable template insights" affects deployment stats but it's not captured outside the description.
Food for thought, not a requirement.
mafredri
left a comment
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.
One suggestion, one question, otherwise 👍🏻 for BE!
| be zero, which will also affect what the bottom deployment overview | ||
| bar displays. Disabling will also prevent Prometheus collection of |
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.
| be zero, which will also affect what the bottom deployment overview | |
| bar displays. Disabling will also prevent Prometheus collection of | |
| be zero. Disabling this will also disable traffic and connection insights in the deployment stats shown to admins in the bottom bar of the Coder UI. | |
| Disabling will also prevent Prometheus collection of |
Ignore indentation.
| } | ||
|
|
||
| // update prometheus metrics | ||
| // update prometheus metrics (even if template insights are disabled) |
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.
Hmm, is this conflicting with the help text added to the deployment flag?
Disabling will also prevent Prometheus collection of [...]
| data={templateInsights?.data?.interval_reports} | ||
| error={templateInsights?.error} |
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.
| data={templateInsights?.data?.interval_reports} | |
| error={templateInsights?.error} | |
| data={templateInsights.data?.interval_reports} | |
| error={templateInsights.error} |
I think a lot of these question marks are no longer needed given the changes to the types
| data={templateInsights?.data?.report?.apps_usage} | ||
| error={templateInsights?.error} |
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.
| data={templateInsights?.data?.report?.apps_usage} | |
| error={templateInsights?.error} | |
| data={templateInsights.data?.report?.apps_usage} | |
| error={templateInsights.error} |
| data={templateInsights?.data?.report?.parameters_usage} | ||
| error={templateInsights?.error} |
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.
| data={templateInsights?.data?.report?.parameters_usage} | |
| error={templateInsights?.error} | |
| data={templateInsights.data?.report?.parameters_usage} | |
| error={templateInsights.error} |
| {!error && !users && <Loader css={{ height: "100%" }} />} | ||
| {(error || users?.length === 0) && <NoDataAvailable error={error} />} |
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 kinda wish we were showing the errors/loading states with early returns or ternarys or something so that these weren't all just independent conditions where we cross our fingers that they're all properly in sync
Closes #20399
I think half of the added lines are just moving the big mock template insights object in the related story.
To summarize the commit messages: