Support slf4j MDC via Apollo audit log？

[BlackBear2003]

Is your feature request related to a problem? Please describe.

Maybe the original audit log display outward function implement by DB and front-end is not very powerful and practicality.

Describe the solution you'd like

So my idea is to support Apollo's slf4j MDC so that users can implement full audit-tracing by modifying logback.xml. Also, users could switch this feature on and off by setting properties like "apollo.audit.log.mdc.enabled=true/false"

Describe alternatives you've considered

Maybe we could implement an Apollo's MDCAdapter and maintaining it via AOP which audit-log has implemented.

Additional context

Please tell me whether this idea is correct and necessary, because I am just a student and have no actual production experience, so my ideas may be biased.🤔

[dosubot]

🤖

Hi @BlackBear2003!

I'm Dosu, a bot here to assist you with your Apollo repository issues and questions. While we're waiting for a human maintainer to join us, feel free to ask me anything related to this project. Remember, no question is too small or too big. I'm here to help!

Your idea of enhancing Apollo's audit log functionality by supporting slf4j MDC is indeed possible. However, the current version of Apollo does not seem to support slf4j MDC in any form based on the provided context.

To implement this, you would need to modify the ApolloAuditProperties class to include a new property for MDC. Here's an example of how you could do this:

package com.ctrip.framework.apollo.audit;

import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties(prefix = "apollo.audit.log")
public class ApolloAuditProperties {

  private boolean enabled = false;
  private boolean mdcEnabled = false; // new property for MDC

  public boolean isEnabled() {
    return enabled;
  }

  public void setEnabled(boolean enabled) {
    this.enabled = enabled;
  }

  public boolean isMdcEnabled() { // getter for new property
    return mdcEnabled;
  }

  public void setMdcEnabled(boolean mdcEnabled) { // setter for new property
    this.mdcEnabled = mdcEnabled;
  }
}

With this change, you can now control the MDC feature through the "apollo.audit.log.mdc.enabled" property. However, you would still need to implement the logic to use slf4j MDC in your logging.

Please note that this is just a basic example and the actual implementation might require more work depending on your specific needs and the current state of the Apollo codebase.

As for your question about the necessity of this feature, it really depends on the specific use cases and requirements of the users. If there is a demand for more powerful and practical audit log functionality, then this feature could be a valuable addition to Apollo.

I hope this helps! If you have any more questions or need further clarification, feel free to ask.

Source Code

-Dosu

Sources

• apollo-audit/apollo-audit-impl/src/main/java/com/ctrip/framework/apollo/audit/ApolloAuditProperties.java

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[nobodyiam]

Implementing SLF4J MDC for operational auditing is a novel approach. Technically, it seems viable. However, I'm interested in understanding why you believe the current method of storing these logs in a database and presenting them with a user-friendly interface lacks effectiveness and practicality. Could you elaborate on your perspective regarding this?
Additionally, the durability of audit logs is essential, ensuring that they can be retrieved for future auditing needs. Therefore, it's crucial to explore how this can be effectively achieved through the SLF4J MDC framework.

[BlackBear2003]

Could you elaborate on your perspective regarding this?

Well, my idea is actually that I am not sure whether others will think the original method is useful.

For the limitation of my front-end abilities, I couldn't represent the relationship between audit logs in a tree structure on the interface. So I have not yet implemented the method of obtaining the audit log from AdminService and displaying it on the front-end interface for avoid to making the front-end looks mess.
So I am temporarily considering that maybe I can print out the tracing process through MDC first?

I found that the information MDC can actually provide is not much more than the original collection method after further thinking in the past two days. And what MDC can actually do has no differences from the original database implementation.
Then, is it still quite a good choice to implementing it?😵‍💫

[nobodyiam]

@Anilople, what are your thoughts on this topic?

[Anilople]

@Anilople, what are your thoughts on this topic?

@nobodyiam @BlackBear2003 I think there are maybe 2 things about it.

1. How to pass the rpc context cross process, for example, from portal to admin service.
2. An audit log extension for user, let user can capture the audit log by self way.

MDC maybe isn't a best way to implement them, though the logging system use logback MDC.

[BlackBear2003]

@nobodyiam @BlackBear2003 I think there are maybe 2 things about it.
How to pass the rpc context cross process, for example, from portal to admin service.
An audit log extension for user, let user can capture the audit log by self way.
MDC maybe isn't a best way to implement them, though the logging system use logback MDC.

Indeed, we already have a more complete cross-process solution than MDC in implementing the Audit log function.
And it seems that MDC could not do much better than the original in data display.