<div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><div>@Lennart  Earlier our unit file had the following definition</div><div><br></div><div><b>StandardOutput=syslog<br>StandardError=syslog<br>SyslogIdentifier=sbagent</b><br></div><div><b><br></b></div><div><b><br></b></div><div>I'm not sure how Systemd was handling this, but my assumption is that systemd redirects STDOUT , STDERR to  /<b>dev/log </b>and then systemd would pick that up and write to the respective file based. Given I found no help with rsyslog to deal with the large size log message (which are few in number) I looked at the journald conf. </div><div><br></div><div>I removed the above explicit definition i.e. <b>StandardOutput etc ..</b>  from the unit file.</div><div><br></div><div><div>And now currently,  our logs are written on STDOUT and STDERR and systemd writes it to journal which `rsyslog` observer redirects them to a specific file(that is what my understanding)</div><div dir="ltr"><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As mentioned you can use the _LINE_BREAK= field to reassemble the<br>lines. But seriously, if you are logging megabytes of data in single<br>log messages you are doing things wrong. Rivisit what you are doing<br>there, you are trying to hammer a square log message into a round log<br>transport. Bad idea.</blockquote><div><br></div><div><br></div><div>@Lennart How? JFI, this is what the split message of a large log message looks like.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">May 22 05:22:38 088c16 echo-command[31926]:. Start ...</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">... 2109876543210987654321098765432109876543210987654321098765432109876543210987654321098765432109876543210987654321098765432109876543210987654<br>May 22 05:22:38 088c16 echo-command[31926]: 32109876543210987654321098765432109876543210987654321098765432109876543210987654321098765... .. End<br> </blockquote><div><br></div><div><br></div><div><b>Start ... End</b> suppose to be a single line but because it reach the upper limit of 48K it was broken. Now how can I assemble them?</div><div> </div><div><br></div><div>Thanks</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 22, 2023 at 2:01 PM Lennart Poettering <<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mo, 22.05.23 09:31, Virendra Negi (<a href="mailto:virendra.negi@sugarboxnetworks.com" target="_blank">virendra.negi@sugarboxnetworks.com</a>) wrote:<br>
<br>
> Ok, I think I get a sense of who is doing what which results in the Large<br>
> Message getting Split as per my understanding it's *LINE_MAX* value in the<br>
> `journalctl` conf that causes the Large message to get split.<br>
><br>
> The default value is 48K and compared to the size of the split message and<br>
> it comes approx to 48K. Now that explains that I'm thinking *is there** a<br>
> way to prepend any "IDENTIFIER"  for the message that was split* from the<br>
> original message? so that we can reassemble/merge them at the central L<br>
> *ogstash* server.<br>
><br>
> I'm looking at the correct section of code,<br>
> <a href="https://github.com/systemd/systemd/blob/main/src/journal/journald-stream.c#L498" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/blob/main/src/journal/journald-stream.c#L498</a><br>
> I<br>
> don't think there exists anything like it. Still want to check if there is<br>
> anything possible?<br>
<br>
As mentioned you can use the _LINE_BREAK= field to reassemble the<br>
lines. But seriously, if you are logging megabytes of data in single<br>
log messages you are doing things wrong. Rivisit what you are doing<br>
there, you are trying to hammer a square log message into a round log<br>
transport. Bad idea.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div>
</div>

<br>
<div><font style="color:rgb(34,34,34);font-family:"trebuchet ms",sans-serif"><font size="3"><img src="https://sugarbox.sgp1.cdn.digitaloceanspaces.com/logo-signature-small.jpg"><br></font><a href="https://www.facebook.com/SugarBoxNetworks/" style="font-size:1.3em" target="_blank"><img src="https://sugarbox.sgp1.cdn.digitaloceanspaces.com/facebook-small.png" style="font-family:Arial,Helvetica,sans-serif;font-size:1.3em"></a><span style="font-size:1.3em"> </span></font><a href="https://www.instagram.com/sugarboxnetworks/" style="font-size:1.3em" target="_blank"><img src="https://sugarbox.sgp1.cdn.digitaloceanspaces.com/instagram-small.png" style="font-size:1.3em"></a><span style="font-size:1.3em"> </span><a href="https://in.linkedin.com/company/margo-networks-pvt.-ltd." style="font-size:1.3em" target="_blank"><img src="https://sugarbox.sgp1.cdn.digitaloceanspaces.com/linkedin-small.png" style="font-size:1.3em"></a></div><div><div style="font-size:small;color:rgb(34,34,34);background-color:rgb(255,255,255);font-family:"trebuchet ms",sans-serif"><br></div></div>
<br>
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><i><b>Disclaimer</b>: This e-mail and any documents, files, or previous e-mail messages appended or attached to it may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this email is strictly prohibited & unlawful. The recipient acknowledges that Margo Networks Private Limited (SugarBox) may be unable to exercise control or ensure or guarantee the integrity of the text of the email message and the text is not warranted as to completeness and accuracy. Before opening and accessing the attachment, if any, please check and scan for virus</i></div></div></div></div><br>