GitAuto: [FEATURE] Add SEQ log provider

[gitauto-ai]

Resolves #216

What is the feature

This feature introduces support for SEQ, a structured log server, by integrating it into our logging infrastructure. A new project, CrispyWaffle.Seq, will be created to include classes that forward logs to a SEQ server using HTTP endpoints. This integration allows us to leverage SEQ's advanced capabilities for structured log management, querying, and visualization.

Why we need the feature

Currently, our logging setup does not support SEQ, limiting our ability to utilize its advanced log management features such as centralized log aggregation, complex querying, and powerful visualization tools. By integrating SEQ, we enhance our logging infrastructure to:

• Improve Log Management: Centralize logs from different components, making it easier to monitor and diagnose issues.
• Leverage Structured Logging: Utilize SEQ's ability to handle structured logs for more meaningful analysis.
• Enhance Debugging and Monitoring: Use SEQ's querying capabilities to filter and search logs efficiently.
• Optimize Development Workflow: Provide developers with better tools to understand application behavior and performance.

How to implement and why

Step 1: Create the CrispyWaffle.Seq Project

• Why: Separating the SEQ integration into its own project maintains modularity and allows for independent versioning and deployment.
• How:
  • Initialize a new class library project named CrispyWaffle.Seq.
  • Configure the project to produce a NuGet package for easy distribution.

Step 2: Implement SeqLogProvider Class

• Why: Implementing ILogProvider ensures compatibility with the existing logging framework and allows SEQ to be configured as a logging endpoint.
• How:

  • Create a class SeqLogProvider that implements the ILogProvider interface.

  • Handle configuration settings such as the SEQ server URL, API key, and message formatting.

  • Implement methods to forward log messages to the SEQ server via HTTP.

  • Example:

    public class SeqLogProvider : ILogProvider
    {
        private readonly SeqConnector _connector;
    
        public SeqLogProvider(SeqConnector connector)
        {
            _connector = connector;
        }
    
        // Implementation of ILogProvider methods
    }

Step 3: Implement SeqBatchLogAdapter Class

• Why: Batching log messages improves performance by reducing the number of HTTP requests and allows for more efficient log transmission.
• How:

  • Create a class SeqBatchLogAdapter that implements the ICategorizedLogAdapter interface.

  • Manage batching of log messages with configurable options like batch size and timeout.

  • Forward batched messages to the SEQ server.

  • Example:

    public class SeqBatchLogAdapter : ICategorizedLogAdapter
    {
        private readonly SeqConnector _connector;
        private readonly TimeSpan _batchTimeout;
        private readonly int _batchSize;
    
        public SeqBatchLogAdapter(SeqConnector connector, TimeSpan batchTimeout, int batchSize)
        {
            _connector = connector;
            _batchTimeout = batchTimeout;
            _batchSize = batchSize;
        }
    
        // Implementation of ICategorizedLogAdapter methods
    }

Step 4: Handle HTTP Communication with SEQ

• Why: Reliable HTTP communication is crucial for ensuring that logs are delivered to the SEQ server correctly.
• How:
  • Use SEQ's HTTP ingestion API or official .NET client libraries to send log events.
  • Implement robust error handling and retries for network failures.
  • Support secure connections (HTTPS) and authentication mechanisms if required.

Step 5: Implement Configurable Batch Behavior

• Why: Allowing users to configure batch settings provides flexibility to balance between performance and real-time logging needs.
• How:
  • Expose configuration options for batch size and batch timeout in SeqBatchLogAdapter.
  • Ensure that default values are sensible for general use cases.
  • Validate configuration inputs to prevent misconfigurations.

Step 6: Testing

• Why: Testing ensures that the integration works correctly and reliably under various conditions.
• How:
  • Write unit tests for SeqLogProvider and SeqBatchLogAdapter.
  • Test sending logs to a test instance of SEQ to verify end-to-end functionality.
  • Simulate network issues to test error handling and retries.

Step 7: Documentation

• Why: Providing clear documentation helps users understand how to configure and use the new logging provider.
• How:
  • Document setup instructions, including how to install the NuGet package.
  • Provide examples of configuring the SEQ server URL, API keys, and batch settings.
  • Include code snippets demonstrating how to integrate SeqLogProvider and SeqBatchLogAdapter into applications.

About backward compatibility

This feature maintains backward compatibility:

• Non-Intrusive Addition: The introduction of CrispyWaffle.Seq is an additive change that does not modify existing interfaces or classes.
• Opt-In Usage: Existing applications are not affected unless they choose to integrate the new SEQ log provider.
• Interface Implementation: By implementing existing interfaces (ILogProvider and ICategorizedLogAdapter), the new classes fit seamlessly into the current logging framework.
• No Breaking Changes: There are no changes to existing code paths or configurations, ensuring that current functionality remains unchanged.

Test these changes locally

git checkout -b gitauto/issue-#216-41d2eceb-2540-44e8-be46-00eae1b32396
git pull origin gitauto/issue-#216-41d2eceb-2540-44e8-be46-00eae1b32396

[github-actions]

Infisical secrets check: ✅ No secrets leaked!

💻 Scan logs

12:27AM INF scanning for exposed secrets...
12:27AM INF 568 commits scanned.
12:27AM INF scan completed in 699ms
12:27AM INF no leaks found

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ -0.03% (target: -1.00%)	✅ ∅

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (403901b)	3874	1642	42.39%
Head commit (2b4ea35)	3874 (+0)	1641 (-1)	42.36% (-0.03%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#578)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[AppVeyorBot]

✅ Build CrispyWaffle 8.2.204 completed (commit b8fd673a27 by @gitauto-ai[bot])

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 39.06%. Comparing base (403901b) to head (2b4ea35).
Report is 21 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #578      +/-   ##
==========================================
+ Coverage   39.04%   39.06%   +0.02%     
==========================================
  Files          83       83              
  Lines        3824     3824              
  Branches      520      520              
==========================================
+ Hits         1493     1494       +1     
- Misses       2228     2229       +1     
+ Partials      103      101       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.