-
Notifications
You must be signed in to change notification settings - Fork 419
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
Provide Munki issues for MacOS hosts #6961
Comments
IC: Determine best data structure for this |
@lukeheath TODO: Update timestamps to UTC and correct docs |
I presume that - as for mdm_id in #6732 - when this filter is provided we will add a
|
@mna Yes, thanks for calling that out. I've updated the specs to reflect adding the |
@lukeheath @noahtalerman Couple non-blocking questions about this ticket:
|
@mna hmm, good question. I prefer option (b). This way, if there's an unknown issue with receiving the version, the errors/warnings will still display. My guess is we delete the host's Munki version information because we assume that Munki is not installed if version is an empty string. Martin, do you know if this is the case?
Error/warnings should replace the previous set. My understanding is that if a Munki error/warning is resolved, Munki no longer reports the error/warning. We'd like Fleet to provide this report of the current Munki errors/warnings. This way, a user can see that a Munki error/warning was removed for X hosts. This will help the user confirm that they resolved the Munki error/warning.
If there's no errors/warnings, we clear up any error/warnings associated with the host. Same "help the user confirm they resolved..." reasoning. |
Yes that's my understanding.
👍 That's what I expected but just wanted to make sure. Makes sense. |
I have some concerns about performance, especially around ensuring the errors/warnings messages have been created and loading their ids when receiving a host's munki info with multiple errors/warnings. I'll add a load testing step to the ticket. |
@lukeheath @noahtalerman Couple more non-blocking questions:
|
I prefer to consider 1 error and 1 warning with same message as 2 different Munki issues in Fleet (different IDs). This is because we'd like to prioritize data accuracy. This means Fleet reports what is reported by Munki. This is an interesting case. Are you running into this while developing the feature?
I'm not sure. I think taking a deeper look into the Munki implementation would be very helpful. Martin, when you get the chance, can you check this out? If it's helpful, I'm happy to hop on a call to dig into this. I would prefer to never truncate the message. This way, we can iterate on the Fleet UI to support longer messages if these are common. Are there performance concerns with not truncating? |
@mna, I forgot to @ mention you in the above message^ |
@noahtalerman Thanks for the clarifications!
👍 sounds good.
No, this is a theoretical case (that we still have to consider) as I have not seen "real" munki data yet (this will likely be a challenge too as I'm on linux and this is mac-only, will likely need some assistance closer to the end of the ticket to get some real data for further testing -
Sure thing, I'll take a look.
Yes, there are performance concerns in terms of both payload size and database performance, as the message needs to have a unique index (well, it will be unique per message + issue type). There are size constraints to unique indexes, and even without constraints, there are performance issues when the indexed data is too big. One option to work around this is to store and index a hash of the string instead of the string itself, which adds complexity around the code logic but is something to consider if we have to. That being said, I'm not sure how valuable a big paragraph of text can be when looking at hosts count and list of hosts with that message, coupled with how likely it is that such long strings could have a few different characters towards the end? But this is definitely a performance-sensitive feature - each host can potentially have a large number of errors+warnings, and the data itself is relatively big (long-ish strings). |
@noahtalerman Took a quick peek at the Munki source code. Looks like everything that calls And this gets called from a number of places in the source code, but this is one example that isn't very encouraging with regards to message size: https://github.com/munki/munki/blob/main/code/client/munkilib/appleupdates/su_tool.py#L279 I'm not fluent in python, but basically any output that comes out from calling If we really want to store large strings, then we'll need the hash approach for the unique index, but we'd still need to cap that string value even if it is a very large maximum (like 2KB or 4KB, something like that is probably reasonable as maximum? I mean, we don't want to store an 1MB message). But storing excessively large values in a column often means using special processing by the DB engine, that is less efficient. |
@lukeheath @noahtalerman In any case for now I'll implement it with a 255 chars limit and load-test the feature - I'm worried that even with smaller messages, we could run into some issues at scale and may need some fine-tuning/caching/etc. Hopefully that's not the case, but there's definitely a risk - this potentially adds significant more data to ingest coming from hosts. On that front, do we have a rough idea of how many issues munki may report with this mechanism (maybe based on how many apps are installed), to run realistic load tests? No rush on that, this won't be ready to load test before some time next week. Otherwise as a guess, I'd think 1 message (warning or error) for 50% of the software installed per host as a kind of "realistic worse case" (maybe for a certain percentage of hosts, 50-80%). |
@mna thank you for digging into the Munki code.
Sounds good 👍
I'm not sure. I'll ask the customer that is requesting this feature and follow up in this issue with the answer.
Thank you for checking this. This is great to be aware of. I agree that this is a minor issue because I don't think semicolons are common characters in Munki errors/warning. I think it makes sense to come back to this later. That is, if I'm wrong and semicolons are common characters in Munki warning/errors. |
Goal
As a Munki administrator, add ability to see the most common Munki issues so that I can prioritize resolving the issues that impact the most hosts.
I also want to be able to see which macOS hosts have these issues so that I know which hosts need issues resolved.
Figma
https://www.figma.com/file/hdALBDsrti77QuDNSzLdkx/%F0%9F%9A%A7-Fleet-EE-(dev-ready%2C-scratchpad)?node-id=7647%3A273670
Related
Tasks
Roles:
1
munki_info
table.name
should be a unique row in the database with an associated id. We will want to retrieve all hosts that contain this munki issuesname
/id
, so a pivot table will likely be necessary.Errors:
SELECT errors FROM munki_info WHERE errors != '';
Warnings:
SELECT warnings FROM munki_info WHERE warnings !=’’;
2
munki_issues
array to theGET /api/v1/fleet/macadmins
response with aggregated counts.team_id
. Example:GET /api/v1/fleet/macadmins?team_id=3
Example response
3
munki_issues
array to theGET /api/v1/fleet/hosts/{id}/macadmins
response with details specific to that host.Example response
4
munki_issue_id
query filter to theGET /hosts
endpoint.munki_issue
in the hosts response. Example:5
osquery-perf
to generate random errors/warnings and load test the data ingestion with many hosts.The text was updated successfully, but these errors were encountered: