Skip to content
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

Ensure consistent logging format for cacti.log #1395

Closed
netniV opened this issue Feb 24, 2018 · 9 comments
Closed

Ensure consistent logging format for cacti.log #1395

netniV opened this issue Feb 24, 2018 · 9 comments
Labels
enhancement General tag for an enhancement gui UI related issue logging Logging issue
Milestone

Comments

@netniV
Copy link
Member

netniV commented Feb 24, 2018

By splitting by line, we can ensure a more consistent log function where multi-line rows are kept inline and neater.

Also, when using the darker colors to highlight errors, we should lighten the text as currently it can be hard to read without copying first.

@cigamit
Copy link
Member

cigamit commented Feb 24, 2018

I'll need to see some examples if what you are saying is that we support a multi-line logging format for a single element. For modern tools, we certainly need to support json output, which if we do one, we do both. However, that does not mean that by default we show it as json (in multiline format). It should be an option though. And I guess if we maintain proper indentation of the json output in the log line, it would be acceptable.

@cigamit cigamit added this to the Cacti Release 1.2 milestone Feb 24, 2018
@cigamit cigamit added enhancement General tag for an enhancement gui UI related issue logging Logging issue labels Feb 24, 2018
@netniV
Copy link
Member Author

netniV commented Feb 24, 2018

It's more where the message field actually contains line break characters, these are automatically placed into the log file. This results in something like:

2018-02-24 08:42:23 SQL: SELECT * FROM hosts
WHERE hostname LIKE '%test%'
AND enabled = ''
AND ...

I was thinking that with the recent regex changes, we could add one that tries to detect the date at the beginning of the line and indent if not found:

2018-02-24 08:42:23 SQL: SELECT * FROM hosts
                    WHERE hostname LIKE '%test%'
                    AND enabled = ''
                    AND ...

or just break up the line as it's written out so it looks like:

2018-02-24 08:42:23 SQL: SELECT * FROM hosts
2018-02-24 08:42:23 WHERE hostname LIKE '%test%'
2018-02-24 08:42:23 AND enabled = ''
2018-02-24 08:42:23 AND ...

However, I do like the JSON idea, except that somethings will not encode into JSON format, so you may have to use serialise instead. The other thing I thought about, could we add microtime as an option to the log so that the timing because clearer, a lot can happen in a second.

@cigamit
Copy link
Member

cigamit commented Feb 24, 2018

What we have been doing for the SQL as a practice is a str_replace("\n", " ", $string) in the logging functions for the SQL. If you review lib/database.php you will find it there in a number of areas. We should really focus on the JSON part for tools like Splunk, Elastic, and other modern NoSQL log storage engines.

@netniV
Copy link
Member Author

netniV commented Feb 24, 2018

Looking at this now, I personally think the second is a good representation.

@netniV
Copy link
Member Author

netniV commented Feb 24, 2018

Yes, but not every bit of code reliable does that. In fact, I think one of the Shutdown or Error Handlers injections the data wrong like above.

@cigamit
Copy link
Member

cigamit commented Feb 24, 2018

Well, I would consider that a bug for the moment. It's a P3 maybe a low P2 issue right now. @ronytomen keeps telling me, focus on 1.2 ;)

@cigamit
Copy link
Member

cigamit commented Feb 24, 2018

There are a few things I don't like about the issue tracker in GitHub vs. Mantis. At least in Mantis we could attach a severity to help us prioritize. I was looking at what Grafana is doing, they have actually been assigning severities in their labels, a crude workaround.

@netniV
Copy link
Member Author

netniV commented Feb 24, 2018

Yeah I was going to say that you could use labels. Either that or you create projects with priorities associated to them

This was created more because I've been meaning to discuss it for a while. On my own plugin, I used the mixture of removing the line feeds with spaces plus added bits to split lines just in case (since others may fork it).

I also did it with router-configs so that the debug output was handled and marked as debug on every debug line (I knew there was something i had forgotten to mention) because when you tried to filter by severity/environ, it was being missed off.

netniV added a commit to netniV/cacti that referenced this issue Mar 3, 2018
@netniV
Copy link
Member Author

netniV commented Mar 3, 2018

This has now been implemented in PR #1439

@netniV netniV closed this as completed Mar 3, 2018
cigamit pushed a commit that referenced this issue Mar 7, 2018
…x in cacti_log() (#1439)

* feature #1395: Ensure messages have each new line keep the same prefix in cacti_log()

* Change multi-line output to use clean_up_lines to create a single line
@netniV netniV changed the title Update cacti_log() function Ensure consistent logging format for cacti.log Dec 31, 2018
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement General tag for an enhancement gui UI related issue logging Logging issue
Projects
None yet
Development

No branches or pull requests

2 participants