Could be, although the Pi uses Systemd/Journal which does logrotation (with size limits) by default. But maybe some process writes to /var/log directly…
Jep 
Unfortunately thunderstorms don’t help (I usually try to avoid opening the enclosure if the humidity is >55-60%RH).
I have installed around 80 Raspi in a range of industrial applications and part of my standard configuration is to run a Cron job to restart the Pi at 2am every day. Never had a problem with a Pi when I do this. They just keep on working, never lock up. Applied this in a Pi1 with the first operating system and right through to a Pi3B+ with systemd.
Could it be that logging to ramdrive is used and logging rotation expects more size than available?
It turned out to be a defective SD card, kernel could not boot…
The file system already broke three weeks prior, but I assumed that simply re-flashing the image will do the job (and did just that). Now that the file system was broken again, I assume it was a defect on the SD card level.
It was one of those cards shipped with the RPi. I hope that the Sandisk Ultra will do better… 
IRC the ones that ship are Sandisk. Some tips may be to move logging into a RAM directory to produce less writes. Another trick I’ve heard of is that a bigger SD card capacity can last longer as while it doesn’t need say a 16GB Card because it can handle more writes it can last slightly longer or such.
Flash memory cell wear can cause different kinds of symptoms, depending on which files are affected. Therefore it may not be directly clear that problems are wear related.
Assuming that the flash wear levelling management performed by the on-card memory controller is perfect (which I doubt) this would imply that there is a linear relation between flash capacity and wear out life expectancy. So a twice larger capacity would mean a twice longer lifetime.
This seems like a logical assumption, but I think the reality will be (much) more complex. So I wonder how much increasing the capacity will actually result in longer correct operation of the flash card. Will it be more linear or will the gains be much less?
Its not clear if SD Cards actually implement Wear Levelling like implemented in a USB. SD cards were created for cameras which write to the same location far less than a Pi. One option is to boot from a USB another is to boot the Pi from a server and not have either an SD Card nor USB. if you stick with the SD Card, you can implement all writing is to RAM disk and the SD Card is write protected so the Pi never writes to the SD card at all.
here is a link to protecting an SD card from sudden power loss https://www.raspberrypi.org/forums/viewtopic.php?t=161416
Or would it be more? As the static content is a smaller portion of the disk there are more sector available to spread the writes resulting in less writes for each sector.
According to this it is not part of the specification but some manufacturers mention it in their specifications.
BTW, I am weary of cheap USB drives as well. Have them fail just like I had SDcards fail.
The (max) linear aspect only accounts the space that is used for dynamically written content, not for static non-changing content.
For a 4 GB flash card, filled 75% with static content only 25% or 1 GB is available for dynamic content.
Going from a 4 GB to a 8 GB flash card with the same 3 GB static content will increase available space for dynamic content from 1 GB to 5 GB, 5 times the size while the size of the card has only doubled.
(And this is a very optimistic scenario. If the size of the static content is only a fraction of the total capacity then doubling the card size will have much less effect on the increase for dynamic content, approaching a factor of 2).
What I was referring to is, if all space available for dynamic content is doubled, will that also double the lifetime or not. There is no simple answer to that because many factors play a role.
I’ve also found based on my experience with Raspberry Pis that usually you’ll only find the better quality in sense of speed (which usually does reflect build quality as well) in the bigger capacities. Also now in most cases its just as cheap to buy bigger, faster ones.
One route that might be worth looking at is SD Cards targeted towards Dashcam users, these can be sold as high endurance or such they are usually made of slightly better flash which in turn lasts longer, some details at http://www.tomsitpro.com/articles/flash-data-center-advantages,2-744-2.html
bought this one a while back… supprised at the speedbump my RPI got
never had any problems
Th packet forwarder outputs a lot of logging onto /var/log/daemon.log. This may overload the /var/log partition (which will stop the gateway) or wear out the SD card (mine is 16 GB). Therefore I changed /etc/rsyslog.conf to minimize logging. I kept a the original version to be be used in case I want to debug the packet forwarder.
That depends on the settings of the forwarder, the forwarder you are running and the way you start it. Most packet forwarders write output to stdout and stderr so you could redirect the output to /dev/null…
The thing is that logging to SD card helps when debugging an issue. But I guess that broken SD cards are the bigger issue than something not working, so I might end up just disabling the persistent journal altogether…
Unless the gateway is on cellular backhaul, you could consider remote logging…
Alternatively (not sure if this has been already mentioned) there are scripts like Log2Ram which will first log to tmpfs and than synch to disk periodically, limiting the number of writes.
(You need to ensure that the packet forwarder log also go to system logs)
Edit – apologies for the noise, just see that we now have a separate topic on that