I am using winston for logging in my application. I have set the log level to info. I can see on my application console that only info or higher level logs are getting printed. But the same is not the case with application insights. I can see that even debug logs are doing into insights, I tried many approaches to avoid this but nothing is working.
and am using the below levels while creating the logger
const levels = {
error: 0,
warn: 1,
info: 2,
http: 3,
verbose: 4,
debug: 5,
silly: 6,
}
Attached a snippet of logger where I am passing levels and level.
I am using botbuilder-applicationisights package, which is collecting all the logs. But, the issue is I want logs at info or higher level to be available in insights not debug levels
Related
I am getting this error (using prisma and graphql), still after looking it up I have no clue what's going on.
Would anyone please help? Thank you!
[Network error]: Error: Task
slick.basic.BasicBackend$DatabaseDef$$anon$2#3a22bdca rejected from
slick.util.AsyncExecutor$$anon$2$$anon$1#cfc0ea7[Running, pool size =
1, active threads = 0, queued tasks = 1000, completed tasks = 497]
Error: Task slick.basic.BasicBackend$DatabaseDef$$anon$2#3a22bdca
rejected from
slick.util.AsyncExecutor$$anon$2$$anon$1#cfc0ea7[Running, pool size =
1, active threads = 0, queued tasks = 1000, completed tasks = 497]
Any other information I can provide to help debugging?
Are you using Prisma's demo servers, and is it working correctly now?
I experienced the exact same error yesterday, even the same completed tasks = 497. In my troubleshooting, the same error happened when 1) I tried to view the Prisma admin console, and 2) when I tried to pull down the schema from Prisma, so I figured the error was coming from something on Prisma's end and it was out of my control.
Today I tried the same things again and they're working correctly! Hopefully they are for you too.
I am having problems running TopShelf as a service and I am not getting much info to help troubleshoot. I am using dotNet core 2.2.
I get this error when I start it:
Error: 1053: The service did not respond to the start or control
request in a timely fashion.
Event logs show:
A timeout was reached (30000 milliseconds) while waiting for the Test service to connect.
The Test service failed to start due to the following error: The service did not respond to the start or control request in
a timely fashion.
It message shows a 30 second timeout in the error popup happens in about 1 second. I don't think its a time out.
I my current setup I am using an IHostedService, but I have tried it without this. Here is the current setup.
var hostBuilder = SetupHost();
var rc = HostFactory.Run(x =>
{
x.Service<IHost>(s =>
{
s.ConstructUsing(name => hostBuilder.Build());
s.WhenStarted(tc =>
{
_logger = tc.Services.GetRequiredService<ILogger<Kickoff>>();
tc.StartAsync();
});
s.WhenStopped(tc => tc.StopAsync());
});
x.RunAsLocalService();
x.SetDescription("Test");
x.SetDisplayName("Test");
x.SetServiceName("Test");
x.EnableShutdown();
x.OnException(p => ExceptionOccured(p));
});
If you see something glaring people let me know.
My main goal is to find a technique to troubleshoot this. I've tried logging to a file with system.io but it does not produce results. I don't know how to debug it or get meaning information.
I'm using aws-flow to interact with Amazon's Simple Workflow Server and I want to get logging set up to go to an external source (PaperTrail).
I've set my $logger to use PaperTrail and I pass this into the client I use to start the execution;
client = Aws::SWF::Client.new(region: 'eu-west-1', logger: $logger)
client.start_workflow_execution({
domain: domain,
workflow_id: ...,
workflow_type: {
name: "...",
version: ...
},
task_list: {
name: "..."
}
})
This successfully logs that the client has started, but no action from inside a Workflow or Activity gets logged.
From reading the documentation and this SO answer it seems like you need to specify a logger when creating new Activities, but I can't see how to do that.
The main workflow uses activity_client to select the Activitiy it needs, and the activity being called looks like;
class MyActivity
extend AWS::Flow::Activities
activity :my_activity do {
default_task_list: '...',
version: ...,
default_task_schedule_to_start_timeout: 60,
default_task_start_to_close_timeout: 60,
exponential_retry: { maximum_attempts: 2 }
}
I can't see anywhere with this setup that you can add a logger to.
Any help would be greatly appreciated
So it turns out aws-flow doesn't support logging.
There is some chat about it in issues and there is a PR which appears to fix things.
For my needs I just forked the project (which at the time of writing hasn't been updated in 2 years) and made the relevant changes for me.
I am trying to debug my jersey 2 app on Payara 162, but on every request, after the trace information is printed I get this exception and the client gets no response:
org.glassfish.grizzly.http.util.MimeHeaders$MaxHeaderCountExceededException: Illegal attempt to exceed the configured maximum number of headers: 100
at org.glassfish.grizzly.http.util.MimeHeaders.createHeader(MimeHeaders.java:396)
at org.glassfish.grizzly.http.util.MimeHeaders.addValue(MimeHeaders.java:422)
at org.glassfish.grizzly.http.HttpHeader.addHeader(HttpHeader.java:707)
at org.glassfish.grizzly.http.server.Response.addHeader(Response.java:1177)
at org.apache.catalina.connector.Response.addHeader(Response.java:1221)
at org.apache.catalina.connector.ResponseFacade.addHeader(ResponseFacade.java:579)
at org.glassfish.jersey.servlet.internal.ResponseWriter.writeResponseStatusAndHeaders(ResponseWriter.java:165)
at org.glassfish.jersey.server.ServerRuntime$Responder$1.getOutputStream(ServerRuntime.java:701)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:200)
at org.glassfish.jersey.message.internal.CommittingOutputStream.flushBuffer(CommittingOutputStream.java:305)
at org.glassfish.jersey.message.internal.CommittingOutputStream.commit(CommittingOutputStream.java:261)
at org.glassfish.jersey.message.internal.CommittingOutputStream.close(CommittingOutputStream.java:276)
at org.glassfish.jersey.message.internal.OutboundMessageContext.close(OutboundMessageContext.java:839)
at org.glassfish.jersey.server.ContainerResponse.close(ContainerResponse.java:412)
at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:784)
at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:444)
at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:434)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:329)
In my jersey I app I configured trace as so:
public class RestApplication extends ResourceConfig {
public RestApplication() {
super();
packages(true, "com.example");
register(JacksonFeature.class);
register(JsonProvider.class);
register(RolesAllowedDynamicFeature.class);
property("jersey.config.server.tracing.type", "ON_DEMAND");
property("jersey.config.server.tracing.threshold", "VERBOSE");
}
}
I enabled the logger in my logback.xml (I have configured Payara to use logback), and I see the full trace info in my server log when I enable it on demand by adding the X-Jersey-Tracing-Accept header to my request, but then I get the exception. When I don't add the header to the request everything works but of course I don't get the trace.
I'm wondering if there is anything I can change to fix this or is it a bug?
The problem is that tracing adds a header into the REST response for each event.
Grizzly imposes a limit on number of headers in the response.
Payara Server by default defines 100 as maximum number of headers in the response. You need to increase this number to allow all tracing info in the response.
To set a higher number for maximum number of headers, you need to use asadmin. There is no option to set this in the GUI admin console, it is missing in the screen to configure the HTTP protocol.
If your configuration is named server-config and the network listener is http-listener-1, then execute the following asadmin command to set it to 1000:
asadmin> set
configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.max-response-headers=1000
You can use a similar command to set all Grizzly network listener propertiesoptions, just replace max-response-headers to the name of the option you want to set, using - as a word separator instead of camel case.
if there is a server error, my XHR will return a 500 error code along with a vague description.
what is the best practice on viewing error logs, debug output, etc?
can this output be sent to my console?
what will work for me now is using the debug object.
var debug = require('debug')('my:debug:string');
then specifying the debug string when launching the app.
DEBUG=my:debug:string node .