hinni / seq-input-mssql Goto Github PK

• Update Seq.Apps to latest version
• Update Microsoft.Data.SqlClient to 4.x

Currently all entries get e fixed level in Seq. This level gets set during configuration.
It would be nice if there was an extra option to obtain the level from the database, so that the original level gets used rather that the one configured during setup.

Add a possiblity to differentiate between several log levels. Currently all log entries are sent to seq as error.

• Define a column name for log levels in the source table or view
• Map the log levels of the source applications to the seq log levels

I am not sure if this is a bug but I am experimenting with this addon and I do not want these types of logs rows to get written to SEQ:

"Query new table rows from 2024-02-12T11:09:06.7894255+01:00 to 2024-02-12T11:09:11.7915443+01:00"

I looked over the code and cannot find a way to disable this.
What can be done, maybe I am not getting something?

Seq Version: 2022.1.7929
Plugin version: 1.2.3 by Hinni Solutions and Contributors

Configuring an instance to consume events from a SQL Server generates the following error:

Looks like there is a bug where the checkpoint file created but no date being inserted if the first call to the sql server fails

It would make sense to do everything in GitHub with Actions. I already removed all Azure DevOps dependencies.

Since the execution log originates from a 3rd party application it would be nice to show that application name in seq.

I query a view that does a few count statements.

When we ran it last week it took about 13sec in ssms. now its up to 26sec.

And in Seq we get the following error message:

A workaround i was thinking about was to do this query with an agentjob and write the result to a table and query this.

Hello.
I think I have correctly configured the application but I get the following error:

I would appreciate if you could give me an idea to solve it.
Thanks.

This is my json config:

{
"Debug": "False",
"QueryEverySeconds": 15,
"ServerInstance": "localhost\SQLEXPRESS",
"ConnectTimeout": null,
"CommandTimeout": null,
"Encrypt": "False",
"TrustCertificate": "False",
"InitialCatalog": "AppGest",
"IntegratedSecurity": "False",
"DatabaseUsername": "UsrAppGest",
"DatabasePassword": "[seq-preserve]",
"TableOrViewName": "LogEvents",
"AdditionalFilterClause": "",
"ColumnNameTimeStamp": "TimeStamp",
"SecondsDelay": null,
"ColumnNameMessage": "Message",
"ColumnNamesInclude": "Properties",
"ApplicationName": "",
"ApplicationPropertyName": "",
"ColumnNameEventLevel": "Level",
"EventLevelMapping": "",
"LogEventLevel": 2,
"TimePeriod": "",
"Tags": "",
"ColumnNameTags": "",
"ColumnNamePriority": "",
"PriorityMapping": "",
"ColumnNameResponder": "",
"ResponderMapping": "",
"ColumnNameProjectKey": "",
"ProjectKeyMapping": "",
"ColumnNameInitialEstimate": "",
"InitialEstimateMapping": "",
"ColumnNameRemainingEstimate": "",
"RemainingEstimateMapping": "",
"ColumnNameDueDate": "",
"DueDateMapping": ""
}

And this is table LogEvents config:

Hi @Hinni,

When DST ends, the same hour occurs twice (eg. 2am - 3am, and then at 3am, the clock changes back to 2am).

At that point, the SQL input will not log any events for an hour, until the clock gets back to 3am.

I'm putting a pull request in that I believe will fix this.

Cheers,

Matt

It would be convenient if the service could be configured to run only for a defined period of time. This is useful for test systems that are shut down at night.