Disable Cloud Foundry RTR Logs
up vote
0
down vote
favorite
Is there any possibility in PCF to disable all PCF related logs and send only Application logs to log-analyzer tool. This would really help.
All the RTR logs are summing up the log sizes in GBs and we would like to see only Application related logs
cloudfoundry pivotal-cloud-foundry
asked Nov 9 at 12:19
Arun
1,27332051
add a comment |
up vote
0
down vote
favorite
Is there any possibility in PCF to disable all PCF related logs and send only Application logs to log-analyzer tool. This would really help.
All the RTR logs are summing up the log sizes in GBs and we would like to see only Application related logs
cloudfoundry pivotal-cloud-foundry
asked Nov 9 at 12:19
Arun
1,27332051
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Is there any possibility in PCF to disable all PCF related logs and send only Application logs to log-analyzer tool. This would really help.
All the RTR logs are summing up the log sizes in GBs and we would like to see only Application related logs
cloudfoundry pivotal-cloud-foundry
asked Nov 9 at 12:19
Arun
1,27332051
Is there any possibility in PCF to disable all PCF related logs and send only Application logs to log-analyzer tool. This would really help.
All the RTR logs are summing up the log sizes in GBs and we would like to see only Application related logs
cloudfoundry pivotal-cloud-foundry
cloudfoundry pivotal-cloud-foundry
asked Nov 9 at 12:19
Arun
1,27332051
asked Nov 9 at 12:19
Arun
1,27332051
asked Nov 9 at 12:19
Arun
1,27332051
asked Nov 9 at 12:19
Arun
1,27332051
asked Nov 9 at 12:19
Arun
1,27332051
1,27332051
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
If you are using a syslog drain to send logs for a specific app to a log aggregator then the short answer is no. You can't stop the Gorouter from logging access entries.
I would go so far as to say that you don't want to either. These logs provides valuable details about the client that is requesting access to your app (IP, user agent, request) & request processing time. This is all critical information to understand if there is a problem you're troubleshooting or worse, if someone is trying to hack your app.
Having said that, I understand that access logs can be a lot of data to process and store. What you can do is to change the rules on your log storage provide. If you really don't want this information and accept the risk of not retaining it, you can drop the entries all together. Otherwise, you can change the retention policy to hold them for a shorter period of time.
If you don't want to/can't filter these on your log aggregator, you could consider implementing a filtering firehose nozzle. This would listen to the firehose and receive log envelopes. Ss @K.AJ mentions, you can do pretty much whatever you want in the nozzle. Your nozzle can filter and drop messages from the Gorouter and/or other services. It's more work than a log drain though. You need to implement the code to send logs off to your log aggregator as well.
There's some details on nozzles and an example here.
Hope that helps!
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
If you are using a syslog drain to send logs for a specific app to a log aggregator then the short answer is no. You can't stop the Gorouter from logging access entries.
I would go so far as to say that you don't want to either. These logs provides valuable details about the client that is requesting access to your app (IP, user agent, request) & request processing time. This is all critical information to understand if there is a problem you're troubleshooting or worse, if someone is trying to hack your app.
Having said that, I understand that access logs can be a lot of data to process and store. What you can do is to change the rules on your log storage provide. If you really don't want this information and accept the risk of not retaining it, you can drop the entries all together. Otherwise, you can change the retention policy to hold them for a shorter period of time.
If you don't want to/can't filter these on your log aggregator, you could consider implementing a filtering firehose nozzle. This would listen to the firehose and receive log envelopes. Ss @K.AJ mentions, you can do pretty much whatever you want in the nozzle. Your nozzle can filter and drop messages from the Gorouter and/or other services. It's more work than a log drain though. You need to implement the code to send logs off to your log aggregator as well.
There's some details on nozzles and an example here.
Hope that helps!
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
add a comment |
up vote
1
down vote
accepted
If you are using a syslog drain to send logs for a specific app to a log aggregator then the short answer is no. You can't stop the Gorouter from logging access entries.
I would go so far as to say that you don't want to either. These logs provides valuable details about the client that is requesting access to your app (IP, user agent, request) & request processing time. This is all critical information to understand if there is a problem you're troubleshooting or worse, if someone is trying to hack your app.
Having said that, I understand that access logs can be a lot of data to process and store. What you can do is to change the rules on your log storage provide. If you really don't want this information and accept the risk of not retaining it, you can drop the entries all together. Otherwise, you can change the retention policy to hold them for a shorter period of time.
If you don't want to/can't filter these on your log aggregator, you could consider implementing a filtering firehose nozzle. This would listen to the firehose and receive log envelopes. Ss @K.AJ mentions, you can do pretty much whatever you want in the nozzle. Your nozzle can filter and drop messages from the Gorouter and/or other services. It's more work than a log drain though. You need to implement the code to send logs off to your log aggregator as well.
There's some details on nozzles and an example here.
Hope that helps!
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
If you are using a syslog drain to send logs for a specific app to a log aggregator then the short answer is no. You can't stop the Gorouter from logging access entries.
I would go so far as to say that you don't want to either. These logs provides valuable details about the client that is requesting access to your app (IP, user agent, request) & request processing time. This is all critical information to understand if there is a problem you're troubleshooting or worse, if someone is trying to hack your app.
Having said that, I understand that access logs can be a lot of data to process and store. What you can do is to change the rules on your log storage provide. If you really don't want this information and accept the risk of not retaining it, you can drop the entries all together. Otherwise, you can change the retention policy to hold them for a shorter period of time.
If you don't want to/can't filter these on your log aggregator, you could consider implementing a filtering firehose nozzle. This would listen to the firehose and receive log envelopes. Ss @K.AJ mentions, you can do pretty much whatever you want in the nozzle. Your nozzle can filter and drop messages from the Gorouter and/or other services. It's more work than a log drain though. You need to implement the code to send logs off to your log aggregator as well.
There's some details on nozzles and an example here.
Hope that helps!
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
If you are using a syslog drain to send logs for a specific app to a log aggregator then the short answer is no. You can't stop the Gorouter from logging access entries.
I would go so far as to say that you don't want to either. These logs provides valuable details about the client that is requesting access to your app (IP, user agent, request) & request processing time. This is all critical information to understand if there is a problem you're troubleshooting or worse, if someone is trying to hack your app.
Having said that, I understand that access logs can be a lot of data to process and store. What you can do is to change the rules on your log storage provide. If you really don't want this information and accept the risk of not retaining it, you can drop the entries all together. Otherwise, you can change the retention policy to hold them for a shorter period of time.
If you don't want to/can't filter these on your log aggregator, you could consider implementing a filtering firehose nozzle. This would listen to the firehose and receive log envelopes. Ss @K.AJ mentions, you can do pretty much whatever you want in the nozzle. Your nozzle can filter and drop messages from the Gorouter and/or other services. It's more work than a log drain though. You need to implement the code to send logs off to your log aggregator as well.
There's some details on nozzles and an example here.
Hope that helps!
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
answered Nov 11 at 18:17
Daniel Mikusa
5,3261814
5,3261814
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53225611%2fdisable-cloud-foundry-rtr-logs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
